310048 - can't set Upgrade header on an XMLHttpRequest

Status: RESOLVED INVALID

Description

[Shiv Kaushal]

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.

Comment 1

[Martijn Wargers (zombie)]

Maybe this has changed with bug 302809?

Comment 2

[Darin Fisher]

Shiv,

Can you post a sample of a request header name and value that you tried to use?

Comment 3

[Darin Fisher]

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?

Comment 4

[Shiv Kaushal]

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

Comment 5

[Shiv Kaushal]

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

[Christian :Biesinger (don't email me, ping me on IRC)]

note but 302263 comment 5

Comment 7

[Darin Fisher]

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.

Comment 8

[Hixie (not reading bugmail)]

Shiv, can you explain the use case for changing protocol here? Specifically, how
would you actually use this?

Comment 9

[Shiv Kaushal]

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

[Hixie (not reading bugmail)]

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.

Comment 11

[Shiv Kaushal]

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

[Daniel Veditz [:dveditz]]

(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