Firefox 20 (beta) declares "Corrupted Content Error" when loading website with Access-Control-Allow-Origin header

VERIFIED FIXED in Firefox 20

Status

()

defect
VERIFIED FIXED
7 years ago
7 years ago

People

(Reporter: andy, Assigned: jduell.mcbugs)

Tracking

Trunk
mozilla22
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox20+ verified, firefox21+ verified, firefox22 verified)

Details

Attachments

(1 attachment)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.99 Safari/537.22

Steps to reproduce:

Loaded http://www.activeinboxhq.com/index.php (also fails on https://www.activeinboxhq.com)


Actual results:

Page shows:

Corrupted Content Error        
The page you are trying to view cannot be shown because an error in the data transmission was detected.
The page you are trying to view cannot be shown because an error in the
 data transmission was detected.
Please contact the web site owners to inform them of this problem.


Expected results:

Firefox 19, Chrome, Safari, etc. all load the page fine. 

Using Charles, and removing the following headers:
Access-Control-Allow-Origin	http://d1it4r8vijv7qb.cloudfront.net
Access-Control-Allow-Origin	https://d1it4r8vijv7qb.cloudfront.net
Causes static files on the site to load.
The error message was added with bug 662414 which is for the new error when a page sends multiple content-length headers.

The page doesn't send a content-length header at all:

Status: HTTP/1.1 200 OK
Transfer-Encoding:	chunked	
Date:	Tue, 26 Feb 2013 22:32:16 GMT	
Connection:	close	
Content-Type:	text/html	
Access-Control-Allow-Origin:	http://d1it4r8vijv7qb.cloudfront.net	
Access-Control-Allow-Origin:	https://d1it4r8vijv7qb.cloudfront.net
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking: HTTP
Ever confirmed: true
Product: Firefox → Core
Furthermore, from the CORS spec (http://www.w3.org/TR/cors/):

> The resource sharing check algorithm for a given resource is as follows:

> * If the response includes zero or more than one Access-Control-Allow-Origin header values, return fail and terminate this algorithm.
I've sent an email.
Assignee: nobody → english-us
Component: Networking: HTTP → English US
Product: Core → Tech Evangelism
Version: 20 Branch → Trunk
Assignee: english-us → josh
Hey Josh, I think www.franke.com has the same problem.  I don't want to send the wrong type of e-mail - could you?
Seeing this issue on the web version of the Playstation Store - https://store.sonyentertainmentnetwork.com/

Full headers:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Allow-Methods: GET
Access-Control-Allow-Origin: https://store.sonyentertainmentnetwork.com/
Access-Control-Allow-Origin: http://store.sonyentertainmentnetwork.com/
Content-Type: text/html; charset=UTF-8
ETag: "280327-221d1-4d58a5e970000"
Last-Modified: Tue, 12 Feb 2013 17:29:36 GMT
Server: Apache
Vary: Accept-Encoding
X-Cache-Lookup: HIT from ip-10.241.1.84:80
X-Frame-Options: SAMEORIGIN
Content-Length: 139729
Expires: Thu, 28 Feb 2013 04:47:26 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Thu, 28 Feb 2013 04:47:26 GMT
Connection: keep-alive
In a couple of these cases, the multiple headers are actually just the HTTP and HTTPS versions of the URL, should these be taken as "suspicious" in this case, or treated as identical and hence not suspicious?
Depends on: 846310
Depends on: 846314
Given that this has already broken one major site, are we sure it's safe to let this go out in 20?
It would be useful to give the sites notified more time, considering 20 is due to land in a few weeks…
Does this mean we need to backout bug 814117? Can someone prepare the backout and nom for uplift if so?
Blocks: 814117
Component: English US → Networking: HTTP
Product: Tech Evangelism → Core
OK, bug 814117 has officially broken too many sites.  We're going to back it out and do a fix at the XHR/CORS level (bug 847533)

This patch is a simple backout of bug 814117, and applies cleanly to all affected branches.  I got verbal +r from bz to do the backout.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 814117
User impact if declined: probably more site breakage  
Testing completed (on m-c, etc.): n/a : just a backout
Risk to taking this patch (and alternatives if risky):  0.0%
String or UUID changes made by this patch: nope
Assignee: josh → jduell.mcbugs
Status: NEW → ASSIGNED
Attachment #725074 - Flags: review+
Attachment #725074 - Flags: approval-mozilla-beta?
Attachment #725074 - Flags: approval-mozilla-aurora?
Keywords: checkin-needed
Comment on attachment 725074 [details] [diff] [review]
backs out bug 814117 on beta/aurora/central

Great - let's get it out.
Attachment #725074 - Flags: approval-mozilla-beta?
Attachment #725074 - Flags: approval-mozilla-beta+
Attachment #725074 - Flags: approval-mozilla-aurora?
Attachment #725074 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/2626965bcf33
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
Reproduced the issue on FF 20b5 with https://store.sonyentertainmentnetwork.com/
Verified fixed FF 20b6, 21.0a2 (2013-03-20), 22.0a1 (2013-03-20) on Mac OS X 10.7.5.
You need to log in before you can comment on or make changes to this bug.