Closed
Bug 431257
Opened 16 years ago
Closed 16 years ago
Netscaler sending invalid headers when redirecting from http:// to https://
Categories
(mozilla.org Graveyard :: Server Operations: Projects, task)
mozilla.org Graveyard
Server Operations: Projects
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: baz, Assigned: mrz)
References
()
Details
(Whiteboard: Citrix # 31764821)
As reported by Phil Homewood: Just thought you'd like to know, addons.mozilla.org is sending broken HTTP headers in response to a request for http://addons.mozilla.org/en-US/ : | HTTP/1.1 302 Object Moved | Server: NS_6.1 | Location: https://addons.mozilla.org/en-US/ | Content Type: text/html | Cache Control: private | Connection: close Note the spaces in "Content Type" and "Cache Control", which should be dashes per RFC 2616. (This upsets some firewalls, which then block the content.) Cheers.... I'm assigning this to Oremj because I believe that the headers are something that he can adjust. Jeremy, if this is not the case, please say so and we'll get someone from the AMO team to take a look. Thanks.
Comment 1•16 years ago
|
||
Seems to only be broken when going to http://addons.mozilla.org (http, not https). NS issue? $ curl -I http://addons.mozilla.org HTTP/1.1 302 Object Moved Server: NS_6.1 Location: https://addons.mozilla.org/ Content Type: text/html Cache Control: private Connection: close
Assignee: oremj → server-ops
Component: Public Pages → Server Operations
Product: addons.mozilla.org → mozilla.org
QA Contact: web-ui → justin
Version: 3.2 → other
Assignee | ||
Comment 2•16 years ago
|
||
The headers are not adjustable. They are generated by the Netscaler. Technically the http VIP is shutdown and the backup or redirectURL is set to https://addons.mozilla.org/ .
Assignee | ||
Comment 3•16 years ago
|
||
(In reply to comment #0) > As reported by Phil Homewood: > > Just thought you'd like to know, addons.mozilla.org is sending broken HTTP > headers in response to a request for http://addons.mozilla.org/en-US/ : Is this breaking specific browser?
Assignee | ||
Updated•16 years ago
|
Assignee: server-ops → mrz
Comment 4•16 years ago
|
||
RFC 2616 specifically defines these standard headers as having the hyphen ("Content-Type" instead of "Content Type", "Cache-Control" instead of "Cache Control", etc.). By using spaces instead of hyphens, Citrix is sending invalid standard headers via the NS and should fix its product not to do so. Upstream ticket time?
Comment 5•16 years ago
|
||
This affects other sites such as http://services.mozilla.com/, too.
Summary: AMO HTTP Headers are malformed → Netscaler sending invalid headers when redirecting from http:// to https://
Assignee | ||
Comment 6•16 years ago
|
||
(In reply to comment #4) > RFC 2616 specifically defines these standard headers as having the hyphen > ("Content-Type" instead of "Content Type", "Cache-Control" instead of "Cache > Control", etc.). By using spaces instead of hyphens, Citrix is sending invalid > standard headers via the NS and should fix its product not to do so. Upstream > ticket time? > I'm not arguing that it shouldn't be fixed. It appears to have been that way for a long time and appears in the 7.0 as well as the 8.0 releases. I was specifically asking if this behavior is breaking any browsers to determine the severity of this issue and how much pressure I need to apply to Citrix.
Reporter | ||
Comment 7•16 years ago
|
||
We don't have any evidence of showing breakage in browsers but the reporter is indicating that firewalls will drop/block the content which has user consequences.
Assignee | ||
Updated•16 years ago
|
Whiteboard: Citrix # 31764821
Assignee | ||
Updated•16 years ago
|
Status: NEW → ASSIGNED
Flags: pending-upstream-fix+
Comment 8•16 years ago
|
||
Fwiw, I just grepped the AMO tree and we are using dashes everywhere.
Assignee | ||
Comment 9•16 years ago
|
||
Moving to projects. Waiting on Netscaler to provide fix.
Status: ASSIGNED → NEW
Component: Server Operations → Server Operations: Projects
Assignee | ||
Comment 10•16 years ago
|
||
Pending fix in 7.0.62 and 8.0.56 at the end of June (tentatively).
Assignee | ||
Comment 11•16 years ago
|
||
7.0.62 just came out but we've moved on to 8.0.56.10 already and that had already been fixed (didn't realize it until just now). mrz@boris [~/] 4> curl -I http://addons.mozilla.org HTTP/1.1 302 Object Moved Server: NS8.0.56.10 Location: https://addons.mozilla.org/ Content-Type: text/html Cache-Control: private Connection: close Resolving.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
HTTP/1.x 302 Object Moved Server: NS8.0.56.10 Location: https://addons.mozilla.org/ Content-Type: text/html Cache-Control: private Connection: close Verified FIXED using Live HTTP headers, making a request for addons.mozilla.org, and getting the above.
Status: RESOLVED → VERIFIED
Updated•9 years ago
|
Product: mozilla.org → mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•