HEAD request to `/login` should not redirect

[osimons]

Bitten now supports 'real' Trac authentication py first making a HEAD request to /login and collecting cookies.

No big deal, but there would be no need for login module to redirect to a GET for project '/' for such requests. If req.method.lower() == 'head' it should just return a 200 ok with cookies and empty body.

[osimons]

Patch that don't redirect on HEAD requests to login or logout.

[osimons]

Anyone mind me committing this to 0.11 and merging to trunk? I think the patch is mostly harmless, and just makes for much more correct behaviour.

[Remy Blank]

Is this an optimization only, or does Bitten depend on the change? In the former case, I would be -1 for the change. As I understand HEAD and GET, the former should return the same headers as the latter, with an empty body (in particular, with a correct "Content-Length"). This would not be true anymore with the patch.

Also, I don't think the optimization is worth the trouble, as Bitten will do at most one request to /login per build, so the effect is negligible.

[osimons]

It is a minor optimization only. I just spotted redirect to '/' with loading of a full page that the HEAD response does not really want or need. It just makes the response more inline with my expectations as I just need the auth cookies from headers. However, I can see that it may break with the specification.

There would be some difference in that the status code would change (303 ⇒ 200), and the location header used for redirect would not be included. Neither response have any body though, so that would not make much difference even if we added some missing headers.

I suppose I could somehow trap this in the client and ignore the redirect, but that makes it much more cumbersome as I'd need to filter out the valid redirects from the ones not to follow… For instance if /login is redirected from old domain name to new domain name by Apache. It isn't that important :-)

[Remy Blank]

Replying to osimons:

It is a minor optimization only. I just spotted redirect to '/' with loading of a full page that the HEAD response does not really want or need.

If you do a HEAD on /login, and you get a redirect to /, doesn't the client also do a HEAD on / afterward (instead of a GET)? That would mean that you shouldn't get the full page after the redirect.

[osimons]

Nope, I get Dispatching <Request "GET u'/'"> in Trac log.

[Remy Blank]

According to ​2616, in 10.3.3, for 302 redirect (which we do on /login):

Note: 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. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

So the client should not change the method, but most do. And indeed, looking at urllib2.HTTPRedirectHandler, the Python implementation does change the method to GET. It would be easy, though, to derive HTTPRedirectHandler in Bitten and override redirect_request() so that it returns a SaneHTTPRequest with a HEAD method instead.

I suggest "wontfix".

[osimons]

Replying to rblank:

I suggest "wontfix".

Oki.