343028 - XMLHttpRequest does a GET after having been redirected from a HEAD

Status: RESOLVED DUPLICATE of bug 598304

(Core :: Networking: HTTP, defect, P3)

Description

[:gerard-majax]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060624 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060624 SeaMonkey/1.5a

XMLHttpRequest (and probably Necko) doesn't follow correclty HTTP redirections. Doing a HEAD works well, until there's a redirection.

Just have a look to this tcpdump :

HEAD /dl/BitTorrent-Stable.exe HTTP/1.1
Host: download.bittorrent.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.1 302 Found
Date: Wed, 28 Jun 2006 11:32:19 GMT
Server: Apache
Location: http://download.bittorrent.com/dl/BitTorrent-4.20.1.exe
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

GET /dl/BitTorrent-4.20.1.exe HTTP/1.1
Host: download.bittorrent.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

Reproducible: Always

Steps to Reproduce:
1. Do a HEAD using XMLHttpRequest
2. Hope the target URL has redirection
3. Notice that we don't end with a HEAD, but a GET.

Actual Results:  
Executed request is GET.

Expected Results:  
Request should be HEAD.

Comment 1

[Darin Fisher]

Hmm... we preserve the HEAD request when the redirect is a 307.  But, we convert all 302 redirects to GET for consistency with older browsers.  However, that generally only applies to the behavior of a POST request.  Perhaps HEAD requests can be treated differently without breaking compat.

What does IE's XMLHTTP implementation do in this situation?

Comment 2

[:gerard-majax]

Dunno, but W3C is clear.

Quoting from http://www.w3.org/TR/XMLHttpRequest/ : 
If the response is an HTTP redirect (status code 301, 302, 303 or 307), then it MUST be transparently followed (unless it violates security, infinite loop precautions or the scheme isn't supported). Note that HTTP  [RFC2616] places requirements on UAs regarding the preservation of the request method during redirects, and also requires users to be notified of certain kinds of automatic redirections.

So, I think that this mean the HEAD have to be kept ?

Comment 3

[Darin Fisher]

In this case, we should do exactly what IE does.  Since you are on windows, it should be pretty easy for you to try it against the same testcase that you used with Firefox.  I'd really appreciate knowing how it behaves.

Moreover, the w3c docs on XMLHttpRequest are still under development.

Comment 4

[Darin Fisher]

Attachment: v1 patch

This patch makes it so that we always preserve the HEAD method when redirected.

Comment 5

[:gerard-majax]

Internet Explorer is doing in the good way ...

@HEAD /dl/BitTorrent-Stable.exe HTTP/1.1
Accept: */*
Accept-Language: fr-fr,fr;q=0.5
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 2.0.50727)
Host: download.bittorrent.com
Content-Length: 0
Connection: Keep-Alive
Cache-Control: no-cache

HTTP/1.0 302 Moved Temporarily
Date: Wed, 28 Jun 2006 21:39:05 GMT
Server: Apache
Location: http://download.bittorrent.com/dl/BitTorrent-4.20.1.exe
Content-Type: text/html; charset=iso-8859-1
X-Cache: MISS from linux.reseau-local.fr
X-Cache-Lookup: MISS from linux.reseau-local.fr:3128
Connection: keep-alive

HEAD /dl/BitTorrent-4.20.1.exe HTTP/1.1
Accept: */*
Accept-Language: fr-fr,fr;q=0.5
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 2.0.50727)
Host: download.bittorrent.com
Content-Length: 0
Connection: Keep-Alive
Cache-Control: no-cache

Comment 6

[Darin Fisher]

ok, then we'll make the same change.

Comment 7

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

Comment on attachment 227457 [details] [diff] [review]
v1 patch

what about the other methods though? should they  really get turned into GET? That doesn't seem to make much sense for PUT or DELETE, for example.

Comment 8

[Darin Fisher]

Agreed, it is tempting to only implement the method change for POST requests, but I wonder about 303 redirects.

Comment 9

[Anne (:annevk)]

If you're going to deviate from the specification I strongly suggest you raise this on [e-mail] first. (And not just cc me on the bug report although I do appreciate that!)

It's unfortunate that some things in the document might indicate that the document is unstable (W3C Process and all that), but the aim is that it's not. That is, the document is driven by implementations. So implementing what the document says is what should be done, unless very good reason A prevents that. Reason A should then be raised on the aforementioned list.

Anyway, it seems like this is just bug fixing in the end.

Comment 10

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

(In reply to comment #8)
> Agreed, it is tempting to only implement the method change for POST requests,
> but I wonder about 303 redirects.

There's also the issue that RFC 2616 10.3 says "The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD."

Comment 11

[Daniel Veditz [:dveditz]]

Comment on attachment 227457 [details] [diff] [review]
v1 patch

sr=dveditz

Should we be preserving HEAD in a 303?

Comment 12

[Darin Fisher]

-> reassign to default owner

Comment 13

[Chris Williams]

What is the status of this issue? As far as I can tell, this problem still occurs under Firefox 3.6.8 for Linux. Was it ever fixed in any version?

This issue has a huge performance impact on an application I am working on. What would I need to do to see it fixed in the next release? (anybody?)

Comment 14

[Julian Reschke]

This seems to be the same as Bug 598304.

Comment 15

[Julian Reschke]

This one can be closed; it has been addressed as part of Bug 598304.