The default bug view has changed. See this FAQ.

XMLHttpRequest does a GET after having been redirected from a HEAD

RESOLVED DUPLICATE of bug 598304

Status

()

Core
Networking: HTTP
P3
normal
RESOLVED DUPLICATE of bug 598304
11 years ago
5 years ago

People

(Reporter: gerard, Unassigned)

Tracking

Trunk
mozilla1.9alpha1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
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

11 years ago
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?
(Reporter)

Comment 2

11 years ago
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

11 years ago
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

11 years ago
Created attachment 227457 [details] [diff] [review]
v1 patch

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

Comment 5

11 years ago
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

Updated

11 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Updated

11 years ago
Priority: -- → P3
Target Milestone: --- → mozilla1.9alpha

Comment 6

11 years ago
ok, then we'll make the same change.
Assignee: nobody → darin
Status: ASSIGNED → NEW
Component: Networking → Networking: HTTP

Updated

11 years ago
Attachment #227457 - Flags: review?(cbiesinger)

Updated

11 years ago
Attachment #227457 - Flags: superreview?(dveditz)
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.
Attachment #227457 - Flags: review?(cbiesinger) → review+

Comment 8

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

Comment 9

11 years ago
If you're going to deviate from the specification I strongly suggest you raise this on public-webapi@w3.org 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.
(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 on attachment 227457 [details] [diff] [review]
v1 patch

sr=dveditz

Should we be preserving HEAD in a 303?
Attachment #227457 - Flags: superreview?(dveditz) → superreview+

Comment 12

10 years ago
-> reassign to default owner
Assignee: darin.moz → nobody
QA Contact: networking → networking.http

Comment 13

7 years ago
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

5 years ago
This seems to be the same as Bug 598304.

Updated

5 years ago
Depends on: 598304
OS: Windows 2000 → All
Hardware: x86 → All

Comment 15

5 years ago
This one can be closed; it has been addressed as part of Bug 598304.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 598304
You need to log in before you can comment on or make changes to this bug.