[HTTPS-E Rulesets] ShareThis - subdomains needing fixes

[Christopher Liu]

To whom it may concern:

I noticed that the blanket rewrite in the last rule of the ShareThis
ruleset seems to hit a few mismatched/broken subdomains. Specifically:

- blog: Exclude (times out)

- edge: Rewrite to wd. Example URL:
http://edge.sharethis.com/share5x/index.5143e87d8032d8713a8a4f85a3735ee1.html
-> https://wd.sharethis.com/share5x/index.5143e87d8032d8713a8a4f85a3735ee1.html
This example was found on blog.sharethis.com; might be for tracking,
as it's not obviously visible on the page (I did at least make sure
the response is HTTP 200 when rewritten)

- s: Rewrite to sd. Example URL: http://s.sharethis.com/loader.js ->
https://sd.sharethis.com/loader.js
Used on blog.sharethis.com, support.sharethis.com, and probably some
third-party sites. It displays a box of share options (Facebook,
Twitter, email...) near the left edge of the screen.

- wd-edge: Rewrite to wd, but the specific URL
http://wd-edge.sharethis.com/button/checkOAuth.esi needs to be
excluded because the rewrite prevents edge-side includes
(<esi:include>) from being parsed, invalidating the JS.
I'm not sure whether this had a valid cert before, but it certainly
doesn't now. (Maybe it moved to a different Akamai service tier? Or
maybe the person testing it added a security exception and forgot
about it?)

(For commenting purposes: support.sharethis.com appears to fully
support HTTPS, in addition to the aforementioned wd and sd. support
uses a CloudFront bucket, d3jyn100am7dxp.cloudfront.net. All
mismatched domains mentioned are on Akamai)

C. Liu
For anything more complex than this, I will try in the future to file
a Trac ticket... sorry for all the emails