Closed
Bug 1278745
Opened 8 years ago
Closed 8 years ago
Amazon product pages giving redirection error
Categories
(Web Compatibility :: Site Reports, defect)
Web Compatibility
Site Reports
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: caspy77, Unassigned)
References
()
Details
(Whiteboard: [country-all] [sitewait] [http])
We've had at least three users reporting that Amazon product pages are giving constant errors. They appear to be internal Firefox errors that read: > The page isn't redirecting properly > Firefox has detected that the server is redirecting the request for this address in a way that will never complete. > This problem can sometimes be caused by disabling or refusing to accept cookies. Here are the three reports I know of: https://support.mozilla.org/en-US/questions/1124338?page=2#answer-884630 https://www.reddit.com/r/firefox/comments/4mrc5l/amazon_product_links_dont_load/ https://www.reddit.com/r/firefox/comments/4mwi6d/amazon_isnt_redirecting_properly/ After extensive troubleshooting the first two were resolved by deleting SiteSecurityServiceState.txt from the profile folder. The third found the amazon line in the file, removed it and the problem went away. Here is the offending line: www.amazon.com:HSTS 2 16959 1496378978047,1,1 I'm guessing there are others with this unresolved recurring problem.
Drew, would you be able to have a look at this?
Flags: needinfo?(stamps)
Comment 2•8 years ago
|
||
For helping with the debugging on Amazon side, Caspy7 could you explain what SiteSecurityServiceState.txt does? When it is set. Thanks.
Honestly, this area is not my expertise. I'm mostly just winging my understanding. As I understand Firefox saves HSTS information in SiteSecurityServiceState.txt. I don't know much more than that. I'll solicit others and folks in #security to chime in if there's more to say.
Flags: needinfo?(caspy77)
Comment 4•8 years ago
|
||
SiteSecurityServiceState.txt is where the browser stores information on the HSTS and HPKP headers sent by the sites https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security I'm not sure what we're storing in the first two numbers. The third is the expiration date (based on a header sent to us by the site in the past) and in this case is June 8. Not sure what the next "1" is, but the final one is the value for includeSubDomains -- in this case "true". Possibly something is trying to load an http: url from a sub-domain that doesn't have the same content on https and that's causing the failure. It is very easy for sites to DOS themselves by sending bad values for either of the HSTS or HPKP headers. We do our best to avoid problems by making sure to honor those headers only if we know it's a working setting for that site. Setting the includeSubDomains option is where sites can get themselves into trouble because we can only test the site you're on, not all possible sub-domain names.
Comment 5•8 years ago
|
||
I'll open an internal issue here at Amazon and see if I can route it to an appropriate resolver.
Flags: needinfo?(stamps)
Comment 6•8 years ago
|
||
Is there any Firefox logging that would give insight into the request/response that was the source of the header values in SiteSecurityServiceState.txt? The presence of these state values is unexpected.
Flags: needinfo?(dveditz)
Comment 7•8 years ago
|
||
There's no historical logging you can inspect on machines already in that state. It looks like you can turn on debug logging if that helps, although you might need an actual debug build for it (I got no output). export MOZ_LOG=nsSSService:5 export MOZ_LOG_FILE=/tmp/moz.log <launch firefox> keeler: is the above correct? does it require a debug build?
Flags: needinfo?(dveditz) → needinfo?(dkeeler)
Comment 8•8 years ago
|
||
Ah, it's MOZ_LOG_MODULES=nsSSService:5 -- the shorter MOZ_LOG only works on recent nightlies but hasn't made it to release yet.
Flags: needinfo?(dkeeler)
Comment 9•8 years ago
|
||
Thank you. My understanding is that the immediate issue that was causing Amazon product pages to be effectively unreachable (infinite redirect) should be resolved.
Comment 10•8 years ago
|
||
This seems to be fixed indeed. Thanks a lot Drew.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•5 years ago
|
Product: Tech Evangelism → Web Compatibility
You need to log in
before you can comment on or make changes to this bug.
Description
•