Closed
Bug 343028
Opened 19 years ago
Closed 13 years ago
XMLHttpRequest does a GET after having been redirected from a HEAD
Categories
(Core :: Networking: HTTP, defect, P3)
Core
Networking: HTTP
Tracking
()
RESOLVED
DUPLICATE
of bug 598304
mozilla1.9alpha1
People
(Reporter: gerard-majax, Unassigned)
References
Details
Attachments
(1 file)
(deleted),
patch
|
Biesinger
:
review+
dveditz
:
superreview+
|
Details | Diff | Splinter Review |
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•19 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•19 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•19 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•19 years ago
|
||
This patch makes it so that we always preserve the HEAD method when redirected.
Reporter | ||
Comment 5•19 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•19 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Updated•19 years ago
|
Priority: -- → P3
Target Milestone: --- → mozilla1.9alpha
Comment 6•19 years ago
|
||
ok, then we'll make the same change.
Assignee: nobody → darin
Status: ASSIGNED → NEW
Component: Networking → Networking: HTTP
Updated•19 years ago
|
Attachment #227457 -
Flags: review?(cbiesinger)
Updated•19 years ago
|
Attachment #227457 -
Flags: superreview?(dveditz)
Comment 7•19 years ago
|
||
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•19 years ago
|
||
Agreed, it is tempting to only implement the method change for POST requests, but I wonder about 303 redirects.
Comment 9•19 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.
Comment 10•19 years ago
|
||
(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•19 years ago
|
||
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•18 years ago
|
||
-> reassign to default owner
Assignee: darin.moz → nobody
QA Contact: networking → networking.http
Comment 13•14 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•13 years ago
|
||
This seems to be the same as Bug 598304.
Updated•13 years ago
|
Comment 15•13 years ago
|
||
This one can be closed; it has been addressed as part of Bug 598304.
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•