Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#8077 closed defect (fixed)

Broken page flow on scientificamerican.com

Reported by: Fry-kun Owned by: MB
Priority: Medium Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Keywords: httpse-ruleset-bug
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Child Tickets

Change History (5)

comment:1 Changed 5 years ago by pde

Owner: changed from pde to MB
Status: newassigned

comment:2 Changed 5 years ago by mikkoharhanen

Some of the problematic urls:
https://www.scientificamerican.com/assets/static/min/root.min.20130131105234.css.pagespeed.ce.5L2SSr9cYA.css
https://www.scientificamerican.com/media/cover/current.cfm.pagespeed.ce.T25G8KT6Gu.jpg
https://www.scientificamerican.com/media/cover/xcurrent.jpg.pagespeed.ic.niBzl7ukx9.jpg

With the right exclusion pattern the page looks nice again:

<exclusion pattern="^http://(?:www\.)scientificamerican\.com/(assets/static|media/cover)/" />

I wonder if there are more problems like this. Some of the content from scientificamerican.com is not available through https.

comment:3 Changed 5 years ago by mikkoharhanen

Resolution: fixed
Status: assignedclosed

I marked this ruleset as mixedcontent and added an exclusion pattern:
https://github.com/mikkoharhanen/https-everywhere/commit/15b6613906a48b46ab653aecaed908e6d3754da5

comment:4 Changed 5 years ago by cypherpunks

I think these exclusions may be overly broad.

Notice that all the problematic URLs contain ".pagespeed." (possibly Scientific American is running an instance of Google Page Speed Service for some of its content?)

As far as I could tell, a rule that strips everything from .pagespeed. onward in www.scientificamerican.com URLs is enough to fix the problem on this and some other blog posts. (To clarify, all the affected pages are on blogs.scientificamerican.com; I did not notice problems with any pages on www.scientificamerican.com. However, the offending files are on the www domain.)

If you don't feel comfortable doing that in any release branch, excluding URLs that contain .pagespeed. is probably a good alternative.

Can someone elaborate as to what other content, if any, is "not available through https"? I haven't seen any problems unrelated to this one; do I need an account?

(I emailed the mailing list about this a few days ago; sorry for not commenting here directly. It doesn't look like anyone's on the CC list for this ticket, but I wasn't sure whether reopening it was an appropriate way to get attention either - sorry for my inexperience w/ Trac)

comment:5 Changed 5 years ago by mikkoharhanen

Your solution is indeed less intrusive. I'm going to remove my exclusion pattern and use the new rules you suggested in https://mail1.eff.org/pipermail/https-everywhere-rules/2013-February/001487.html

I could not find any other content that wasn't working with these rules so this looks like a great solution.

https://github.com/mikkoharhanen/https-everywhere/commit/414a862bb710754a973a8b8b0dd5be54fb99937a

Note: See TracTickets for help on using tickets.