Why do keepalives reply with a Location: header?

[Steven R. Loomis <srl@…>]

Bitten Trunk r881 + trac 0.12.

I upgraded from WSGI to fcgid (but that's another story). Now I am seeing this pattern in my logs:

"POST /trac/builds/69/keepalive/ HTTP/1.1" 302 230
"GET /trac/builds/69/keepalive HTTP/1.1" 404 4879
Trac[main] WARNING: HTTPNotFound: 404 Not Found (No handler matched request to /builds/69/keepalive)

but…

Trac[master] INFO: Slave ibm-9c7b build 69 keepalive ("icu4c" as of [28305])

So, it's being kept alive. I wondered why the 302 bounce to 404. The GET is bogus of course, as it should be a POST.

The bitten master code for a keepalive has this:

        self._send_response(req, 200, body, {
                            'Content-Type': 'text/plain',
                            'Content-Length': str(len(body)),
                            'Location': req.abs_href.builds(
                                    build.id, 'keepalive')})

looks like someone (fcgid? apache? Bueller??) 'helpfully' turned a Location: into a 302 redirect, which SaneHTTPRequest retried as a GET (probably an error, but whatever).

The slave doesn't actually look at the Location: header. Why is it there?

[Steven R. Loomis <srl@…>]

I failed to patch around this, so I wasn't able to see if removing Location: fixed it, yet. I'm just going to ignore it.

[osimons]

Walter? Should handle this issue before any 0.6 release.

[wbell]

Hadn't seen this one. I'll take a look at this.

[anonymous]

From looking at the code, I included the 'Location' field to be consistent with the other responses from the master. I have no issue with removing it and will do so. I'm not quite sure what the issue is however-- any thoughts on who is creating the second request and why? Do you see this double request on other build slave related operations (step complete, etc.)

[Steven R. Loomis <srl@…>]

​RFC 2616 §14.30 : The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource.

The double request is happening because the trac server is proxied - and someone is "helpfully" turning Location into a 302 Found (redirect). I think the Python HTTP call on the slave's side is just following the redirect.

So, the issue is that Bitten is setting a confusing and inappropriate HTTP header.

[wbell]

Interesting. You learn something new every day. There are 3 locations where the 'Location' header is returned:

• From the build creation.
• From a build step completion.
• From keepalives.

I feel like all 3 are wrong (although the result of the build creation 'Location' field is used by the slave.)

I've run this with polipo (a caching web proxy) and cannot reproduce this issue. This close to a release, I'm not going to change all 3 locations; since we're not using the 'Location' field on keepalives, there's no harm in removing it. If you run into other issues with your proxy, please file additional issues.

[wbell]

Fixed as of [904]