[HTTPS-E Rulesets] Raymond.cc is broken; possible fix for Discogs; other minor issues

[Christopher Liu]

To whom it may concern:

This message concerns additions and removals in existing rulesets.
It does not contain inquiries about possible/uncertain typos nor
style/commenting issues; I'll hold those for later. With that said...

The Raymond.cc ruleset is now completely broken; neither
www.raymond.cc nor cdn.raymond.cc responds to https requests anymore.
Discogs: The first $2 should be $1; it seems this was neglected when
some patterns were made non-capturing. This may be relevant to
https://trac.torproject.org/projects/tor/ticket/6285

- Other major issues -

Dailymotion:
As the ruleset currently stands, the video itself fails to play, and
the page layout is severely messed up from the failure of most
images/CSS/JS. However, the thumbnails of related videos do seem to
load successfully.
static[12]-ssl.dmcdn.net now exist; we should probably rewrite to
there instead. static1-ssl already sees some use in https pages.
The fix appears to involve the following exclusions (both are necessary):
   ^http://(www\.)?dailymotion\.com/crossdomain\.xml$
   ^http://(www\.)?dailymotion\.com/cdn/[\w\-]+/video/
and also limiting the dmcdn rule to user avatars and video thumbnails:
   rule from="^http://static(\d)(?:-ssl)?\.dmcdn\.net/static/(.+)\.jpg"
to="https://static$1-ssl.dmcdn.net/static/$2.jpg"
The securecookie doesn't appear to harm anything, though I am not a
registered user.
The dmcloud stuff still works correctly.
Some pages to test with:
http://www.dailymotion.com/video/xeva16_fds-eggerland-in-36-58-98-by-adelik_videogames
http://www.dailymotion.com/video/xe1x7j

US government:
In the rule that deals with (www.)fnal.gov, the "to" field has the TLD
misspelled as "fov."

- and "other minor issues" -

BYU (Brigham Young University):
At least some of www.et.byu.edu is broken. For example,
photonics.byu.edu has www.et.byu.edu/groups/photonics/favicon.ico as
its favicon. When fetched over https, this redirects to
https://photonics.groups.et.byu.net/favicon.ico which validates but
403s.
I've never been formally affiliated with BYU in any way, so I'm not
sure where to continue testing. In particular, I have no way to verify
whether there is a campus IP restriction involved here.

Gravatar:
The [012].gravatar.com domains support https natively now.
Example pages: http://thereifixedit.failblog.org/2010/10/26/white-trash-repairs-so-cute-you%E2%80%99ll-forget-to-call%C2%A0cps/
(where the items are not already https);
https://jonoscript.wordpress.com/2012/04/26/gmail-designer-arrogance-and-the-cult-of-minimalism/
(where the items are already https)

HP:
Add h30495.www3.hp.com; eprintcenter.com redirects there.
Also, h10025.www1.hp.com (used for driver download pages, e.g.
https://h10025.www1.hp.com/ewfrf/wc/softwareCategory?cc=us&lc=en&dlc=en&product=4083977
)

PCPro.co.uk:
The CloudFront bucket is desawk404a9v3.cloudfront.net for both photos
and sprites. Rewriting as such appears to work fine.

RFC-Editor:
The errata search feature is redirecting to http. An exclusion that
seems to work is ^http://(www\.)?rfc-editor\.org/errata(_search)?\.php
(do not add $ as there are query parameters). All other pages/content
still work in https. I may have mentioned this a while back but didn't
explain myself clearly.

Telegraph Media Group:
The last rule attempts to rewrite i.fantasyfootball.telegraph.co.uk to
its EdgeCast bucket; most (all?) of the images supposedly covered by
this currently fail to load.
I'm not sure whether there is some mistake in the rule or whether it
is broken for other reasons. (The 437A identifier still seems correct,
but should the subdomain be gs1.wac rather than just gs1? Is gp1 in
the comment a typo? Feel free to remove the rule while you
investigate.)


As usual... sorry for any incovenience, and thank you very much for your help.

C. Liu