Closed
Bug 310048
Opened 19 years ago
Closed 9 years ago
can't set Upgrade header on an XMLHttpRequest
Categories
(Core :: Networking: HTTP, defect)
Core
Networking: HTTP
Tracking
()
RESOLVED
INVALID
People
(Reporter: shivkaushal, Unassigned)
References
()
Details
(Keywords: regression)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.12) Gecko/20050922 Red Hat/1.0.7-1.4.1.SL3 Firefox/1.0.7 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.12) Gecko/20050922 Red Hat/1.0.7-1.4.1.SL3 Firefox/1.0.7 I modified this test pagfe from the mozilla site http://www.mozilla.org/xmlextras/get.xhtml and placed p.setRequestHeader('MyHeader', 'MyValue'); immediately after the p.open() line - as per the spec. This worked fine in 1.0.6 both on Windows and Linux and is now broken in 1.0.7 AND 1.5 beta. I have tested this on my own Apache web server while looking at the logs, specifically configured to log the values for MyHeader. Reproducible: Always Steps to Reproduce: 1. Get and Apache server running and configure logs to print value of 'MyHeader' - usually the LogFormat line in the httpd.conf 2. Modify the page at http://www.mozilla.org/xmlextras/get.xhtml to include the setRequestHeader() 3. Access page with 1.0.6 and then with either 1.0.7 or 1.5 beta and then look at logs Actual Results: With new versions the request header appears not to have been set! Expected Results: The extra header information should be passed on to the web server as in previous verions. I have tried this with clean installs (i.e. blank profiles) of 1.0.7 and 1.5 beta and cannot get this to function correctly - hence this report. Javascript console reports no errors in 1.0.7 and there are some errors in the 1.5 beta console - but these appear to be reported elsewhere and unrelated. I think this is a major feature problem as any pages/extensions making use of setRequestHeader functions for web services AJAX purposes are rendered useless.
Updated•19 years ago
|
Updated•19 years ago
|
Assignee: nobody → darin
QA Contact: general → networking.http
Comment 2•19 years ago
|
||
Shiv, Can you post a sample of a request header name and value that you tried to use?
Comment 3•19 years ago
|
||
Hmm... if I call setRequestHeader("MyHeader", "MyValue") after open, then it works as expected. I tested with Firefox 1.0.4, 1.0.7, and 1.5b1. They all behave identically. Shiv, Can you please provide more details or possibly a live testcase?
Reporter | ||
Comment 4•19 years ago
|
||
Ok. Here is the actual test page I am using... you can look at the source code, but you will probably get a 403 error because authenications is done over https with X.509 user certificates. What I can sya for sure is that I have tried this exact page on two seperate machines before and after installing 1.0.7 and 1.0.7 breaks it. The header being added is "Upgrade: GridHTTP/1.0" which is a protocol I am working on as part of my PhD work. I can post apache server logs if anyone is interested.... Cheers, Shiv
Reporter | ||
Comment 5•19 years ago
|
||
ok... i Know. Here is the link http://pc78.hep.man.ac.uk/test/test.html Even in http mode the header request doesn't appear in the log for 1.0.7: pc78.hep.man.ac.uk - - [26/Sep/2005:12:54:15 +0100] "HEAD /test/test.mp3 HTTP/1.1" 200 - "-" "Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.12) Gecko/20050922 Red Hat/1.0.7-1.4.1.SL3 Firefox/1.0 .7" Upgrade:"-" But beforehand with 1.0.6 it did work: pc78.hep.man.ac.uk - - [26/Sep/2005:12:43:20 +0100] "HEAD /test/test.mp3 HTTP/1.1" 302 - "-" "Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050912 Red Hat/1.0.6-1.4.2.SL3 Firefox/1.0 .6" Upgrade:"GridHTTP/1.0"
Comment 6•19 years ago
|
||
note but 302263 comment 5
Summary: setRequestHeader() doesn't do anything for an XmlHTTPRequest → can't set Upgrade header on an XMLHttpRequest
Comment 7•19 years ago
|
||
NOTE: you can still set the Upgrade header if your script has the UniversalBrowserWrite capability. It's not a great solution, but it could be used to get around this new restriction. Confirming bug. This may end up being WONTFIX.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 8•19 years ago
|
||
Shiv, can you explain the use case for changing protocol here? Specifically, how would you actually use this?
Reporter | ||
Comment 9•19 years ago
|
||
What happens is this: A user tries to connect to the server over https using an X.509/Grid certificate to authenticate. IF the user specifies that they support GridHTTP (via the Upgrade header) and the server understands, it redirects the user to an HTTP version of the file that can only be accessed once. This is purely for performance purposes (cutting out the encryption/decryption overhead) but allows SOME level of security as the redirect is ONLY returned if the client is recognised by their X.509 cert. AND has access to the file. It doesn't protect against man in the middle attcks over HTTP but we are aware of that... For those that are in the know - this is exactly the same as the risks involved with the Globus GridFTP protocol. I am eventually going to be implementing this in an extension so that I can let users right-click a link and choose "get with GridHTTP" or something similar. What would I need to do to enable unversal browser read and would this be enough to make my extension work? Is this restricted to the Upgrade header only?
Comment 10•19 years ago
|
||
What you describe doesn't seem to be the right use of the Upgrade: header. Wouldn't a custom header be more appropriate? Like, "X-GridHTTP: 1" or similar? The Upgrade header implies the server should send back a 101 HTTP response, and the client should include Connection: upgrade, and all kinds of other things.
Reporter | ||
Comment 11•19 years ago
|
||
Sadly, changing the spec is not under my control - I am just writing a client-side tool to match several exisiting methods of doing this from command line.
Comment 12•19 years ago
|
||
(In reply to comment #9) > I am eventually going to be implementing this in an extension so that I can let > users right-click a link and choose "get with GridHTTP" or something similar. > What would I need to do to enable unversal browser read and would this be enough > to make my extension work? Extensions can set any header they like, they are privileged. > Is this restricted to the Upgrade header only? No, there are currently five. http://lxr.mozilla.org/mozilla/source/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp#1634 er, why wasn't bug 308484 checked in on the trunk? This is what it should look like: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp&rev=MOZILLA_1_7_BRANCH#1577
Updated•18 years ago
|
Assignee: darin → nobody
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•