Component: General → XML
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
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.