Opened 6 years ago

Last modified 4 years ago

#4593 reopened defect

Breaks goodreads.com / cloudfront.net

Reported by: daw-bugzilla Owned by: pde
Priority: Medium Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Keywords:
Cc: MB Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Visiting http://www.goodreads.com/ with HTTPS Everywhere enabled causes some functionality of Goodreads to be broken. In particular, some of the images are not properly displayed.

To test: Create an account on Goodreads. Go to the web page for some book, say this one:
http://www.goodreads.com/book/show/29579.Foundation
Rate the book 4 stars by clicking on the 4th star. Notice how the leftmost 4 stars are now lit up to orange. Now reload the page. You will find that the orange is gone; all five stars are now shaded grey.

Possibly related: If you open up the Firefox Error Console, you will see lots of errors. Here is one that seems to be representative:

Error: [Exception... "'Image HTTP->HTTPS redirection to https://dkt27ch3b0vq7.cloudfront.net/images/loading-trans.gif?1322099299' when calling method: [nsIContentPolicy::shouldLoad]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "<unknown>" data: no]

There are dozens and dozens of these exceptions in the Error Console.

It looks like Goodreads is using Amazon's Cloudfront service as a CDN, to host images. Thus, the Goodreads web page has a HTTP link to something on cloudfront.net. I'm guessing HTTPS Everywhere is rewriting the cloudfront.net URL to use HTTPS. At some point in this chain it appears that something goes wrong, though I'm not sure what exactly.

I can confirm that if I go to the HTTPS Everywhere preferences, select the Cloudfront site, and disable HTTPS Everywhere for that site, then everything seems to work fine: the page displays properly (the stars on the page show up orange, as they should), and there are no errors in the Firefox Error Console.

Child Tickets

Change History (8)

comment:1 Changed 6 years ago by daw-bugzilla

By the way, I found a blog post from someone else reporting problems with HTTPS Everywhere and Cloudfront. I'm not sure if it is relevant at all, but I'm posting here in case it seems relevant to someone else:

http://blog.sambao21.com/post/9886998008/amazon-cloudfront-https-everywhere-503
https://forums.aws.amazon.com/thread.jspa?messageID=255884

Again, these URLs might be totally irrelevant.

comment:2 Changed 6 years ago by pde

Resolution: worksforme
Status: newclosed

This seems to be working for me now, but please reopen this if it the bug is still around and I'll look closer.

Also, should we have a ruleset for goodreads.com?

comment:3 Changed 6 years ago by daw-bugzilla

Resolution: worksforme
Status: closedreopened

I'm re-opening, as it is still broken for me. I confirmed I can still reproduce it by following the instructions listed above. Dunno if it is something specific about my browser, platform, or network location.

Is there any information I can provide that would help troubleshoot, or anything else I could do that would help? I'm using Firefox 3.6.24 on Fedora Linux 14 (x86_64), with HTTPS-Everywhere 1.2.2 (and a few other extensions, e.g., AdBlock Plus 2.0.3; plus privoxy-3.0.16-3.fc4.x86_64). In case it helps to see the DNS resolution of the two hosts mentioned in the bug report from where I sit in the network, here they are:
$ host www.goodreads.com
www.goodreads.com is an alias for goodreads.com.
goodreads.com has address 216.74.34.10
goodreads.com mail is handled by 30 alt2.aspmx.l.google.com.
goodreads.com mail is handled by 40 aspmx2.googlemail.com.
goodreads.com mail is handled by 50 aspmx3.googlemail.com.
goodreads.com mail is handled by 10 aspmx.l.google.com.
goodreads.com mail is handled by 20 alt1.aspmx.l.google.com.
$ host dkt27ch3b0vq7.cloudfront.net
dkt27ch3b0vq7.cloudfront.net is an alias for dkt27ch3b0vq7.sfo5.cloudfront.net.
dkt27ch3b0vq7.sfo5.cloudfront.net has address 205.251.215.172
dkt27ch3b0vq7.sfo5.cloudfront.net has address 205.251.215.238
dkt27ch3b0vq7.sfo5.cloudfront.net has address 205.251.215.104
dkt27ch3b0vq7.sfo5.cloudfront.net has address 205.251.215.151
dkt27ch3b0vq7.sfo5.cloudfront.net has address 205.251.215.180
dkt27ch3b0vq7.sfo5.cloudfront.net has address 205.251.215.91
dkt27ch3b0vq7.sfo5.cloudfront.net has address 205.251.215.82
dkt27ch3b0vq7.sfo5.cloudfront.net has address 205.251.215.187

comment:4 Changed 6 years ago by pde

One thing that could be helpful would be the particular URL of an image or other request within the page that is failing.

comment:5 Changed 6 years ago by daw-bugzilla

Unfortunately I can't seem to find any image or other resource within the page that I can verify is failing. All I have are the errors in the Firefox Error Console, but if I take one of those URLs and load it into its own window, it loads properly (with no error). So I don't really understand what is going on or why Goodreads is breaking for me.

Sorry, I realize that this is a lousy bugreport. I'll see if I can come up with anything more reproducible and actionable.

comment:6 Changed 5 years ago by pde

Cc: MB added

In a recent bugfix for Amazon Search Inside The Book, I realised that there was a particular Cloudfront subdomain that Amazon always used, and we could exclude that to prevent breakage.

Perhaps this is true for Cloudfront in general? If so, and if this bug still exists, should we try excluding dkt27ch3b0vq7.cloudfront.net or whatever CF domain Goodreads is currently using?

comment:7 Changed 5 years ago by pde

Resolution: worksforme
Status: reopenedclosed

Well, I just tried but can't reproduce the underlying problem. So I'm going to close this again, but if the bug resurfaces we can try the cloudfront subdomain exclusion.

comment:8 Changed 4 years ago by mattflaschen

Resolution: worksforme
Status: closedreopened

Droplr's Cloudfront domain doesn't work either (https://d1zjcuqflbd5k.cloudfront.net).

Pick something from https://www.google.com/search?q=inurl%3Ad.pr%2Fi#q=inurl:d.pr/i&filter=0 to test.

When you open the image directly in a new tab, it says AccessDenied. Of course, you can blacklist this subdomain. But I'm not sure if Amazon has SSL configured to work or not by default on Cloudfront. If it's off by default, that should probably be the HTTPSEverywhere default (then enable for subdomains where it works).

Note: See TracTickets for help on using tickets.