Bug 42663 – Redirected HEAD requests become GET requests

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: Page Loading

[Daniel Rodríguez Troitiño]

Created attachment 62109 [details]
Sinatra server proving the error.

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
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; es-es) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16
Accept: */*
Referer: http://localhost:9393/
Accept-Language: es-es
Accept-Encoding: gzip, deflate
Cookie: __utma=111872281.992253814905347300.1237204323.1246625184.1249551661.9
Content-Length: 0
Connection: keep-alive

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
Accept-Encoding: gzip, deflate
Accept-Language: es-es
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; es-es) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16
Accept: */*
Referer: http://localhost:9393/
Cookie: __utma=111872281.992253814905347300.1237204323.1246625184.1249551661.9
Connection: keep-alive

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.

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

[Anne van Kesteren]

I'm pretty sure this got fixed (aka CONFIGURATION CHANGED), but suspect this isn't handled by WebKit directly. Youenn?

[youenn fablet]

Hum, we used to have some platform specific code that was dealing with this wrongly but this has probably been fixed since a long time.
Marking a configuration changed.