New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users

Issue metadata

Status: Duplicate
Merged: issue 102130
Owner: ----
Closed: Nov 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

Redirected HEAD requests become GET requests

Reported by drodrigu...@gmail.com, Jul 20 2010

Issue description

Chrome Version       : 5.0.375.99 (Build oficial 51029) WK: 533.4 V8: 2.1.10.14
Other browsers tested: Safari 5, Firefox 3.5.5, IE8, Opera 10.10
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: FAIL
  Firefox 3.x: FAIL
         IE 7: ?
         IE 8: OK
         Opera 10.10: FAIL

What steps will reproduce the problem?
1. Setup a server that will do a redirect from URL A to URL B.
2. Create a web page that does a XHR HEAD request to A when clicking a link.
3. Click the link.

What is the expected result?
The first HEAD request should be redirected, producing a second HEAD request in the URL B.

What happens instead?
The second request is actually a GET request.

Please provide any additional information below. Attach a screenshot if
possible.

I have setup a simple web server with 3 endpoints:
- '/' will serve a web page (described below)
- '/redirect_me' will redirect to '/redirected'
- '/redirected' will include a 'X-Request-Method' header with the kind of request of the client (either GET or HEAD).

The web page is a simple web page that includes jQuery 1.4.2, a link, and an 'click' event in the link that fires a XHR setting the method to HEAD to the URL /redirect_me. I was expecting that the request will be redirected, and the next request will be a HEAD, but it is actually a GET. This can be seen inspecting the headers of the response (set by the server to be the request method used by the client), or sniffing the transmissions between client and server.

This is the captured communication:
---
HEAD /redirect_me HTTP/1.1
Host: localhost:9393
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4
Referer: http://localhost:9393/
Content-Length: 0
Cache-Control: max-age=0
X-Requested-With: XMLHttpRequest
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: es-ES,es;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: remember_token=91614ccb39dc83c0b9c83924074e48bd1c931073

HTTP/1.1 302 Moved Temporarily
Location: /redirected
Content-Type: text/html
Content-Length: 0
Connection: keep-alive
Server: thin 1.2.7 codename No Hup

GET /redirected HTTP/1.1
Host: localhost:9393
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4
Referer: http://localhost:9393/
Cache-Control: max-age=0
X-Requested-With: XMLHttpRequest
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: es-ES,es;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: remember_token=91614ccb39dc83c0b9c83924074e48bd1c931073

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0
X-Request-Method: GET
Connection: keep-alive
Server: thin 1.2.7 codename No Hup
---

As you see, the redirection is a Status 302, and I haven't been able to find a final answer to what a client should do in case of a HEAD redirect. The RFC has a note under the 302 Found epigraph <http://tools.ietf.org/html/rfc2616#section-10.3.3>: "RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request.  However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method." Testing with 303 behaves like with 302, and 307 behaves correctly doing 2 HEAD requests.

In my opinion, the implementation of the 302 status for HEAD requests is incorrect, because the RFC states that <http://tools.ietf.org/html/rfc2616#section-9.4> "the server MUST NOT return a message-body in the response". Converting the HEAD request into a GET request, modifies the expectation of the client that no response body will be downloaded, so I think this behaviour should be corrected.

I have made test in several browsers, and unfortunately Safari, Chrome and Firefox behave incorrectly (in my opinion), while IE8 and cURL do two HEAD requests. Opera 10.00 do not follow the redirection for the HEAD request. I will be filling similar bugs in all of them to sort this issue out.

The bug in WebKit bugzilla is <https://bugs.webkit.org/show_bug.cgi?id=42663>. Chrome behaves exactly as WebKit, so maybe this a problem in WebKit, actually.

(I attach the code, a little server implemented with Sinatra <http://sinatrarb.com> which proves the error)
 
header.rb
1.3 KB View Download

Comment 1 by wtc@chromium.org, Feb 1 2011

Labels: -Area-Undefined Area-Internals Internals-Network Area-WebKit

Comment 2 by karen@chromium.org, Feb 15 2011

Labels: kmoved-021511 Mstone-X
This is likely a duplicate of https://code.google.com/p/chromium/issues/detail?id=102130
Mergedinto: 102130
Status: Duplicate
Project Member

Comment 5 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
Mergedinto: chromium:102130
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 6 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Internals-Network -Area-WebKit Cr-Content Cr-Internals Cr-Internals-Network
Project Member

Comment 7 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink

Sign in to add a comment