Closed Bug 310048 Opened 20 years ago Closed 10 years ago

can't set Upgrade header on an XMLHttpRequest

Categories

(Core :: Networking: HTTP, defect)

defect
Not set
major

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.
Component: General → XML
Keywords: regression
Product: Firefox → Core
Version: unspecified → Trunk
Maybe this has changed with bug 302809?
Component: XML → Networking: HTTP
Assignee: nobody → darin
QA Contact: general → networking.http
Shiv, Can you post a sample of a request header name and value that you tried to use?
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?
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
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"
note but 302263 comment 5
Summary: setRequestHeader() doesn't do anything for an XmlHTTPRequest → can't set Upgrade header on an XMLHttpRequest
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
Shiv, can you explain the use case for changing protocol here? Specifically, how would you actually use this?
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?
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.
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.
(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
Depends on: 308484
Assignee: darin → nobody
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.