Walrus incorrectly provides content on HEAD request

[Anthony Awtrey]

According to HTTP 1.1 specifications (rfc2616, section 9.4):

"The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response."

However, when using HEAD to query a non-existent key, Walrus will include <Error /> content as XML in the reply. Using boto as a test client shows this:

HTTP Request:

HEAD /services/Walrus/upload-test/file.txt HTTP/1.1\r\nHost: 192.168.69.44:8773\r\nAccept-Encoding: identity\r\nDate: Wed, 07 Sep 2011 16:40:56 GMT\r\nContent-Length: 0\r\nAuthorization: AWS blah:blah\r\nUser-Agent: Boto/2.0 (linux2)\r\n\r\n

HTTP Response:

HTTP/1.1 404 Not Found\r\nContent-Length: 283\r\nContent-Type: application/xml\r\n\r\n<Error xmlns="http://s3.amazonaws.com/doc/2006-03-01/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><Code>NoSuchEntity</Code><Message>The specified entity was not found</Message><Resource>file.txt</Resource><RequestId>1e6b9a72-f49c-42d1-8c2e-56c9e08f8177</RequestId></Error>

The correct behavior is to limit responses to HEAD requests to HTTP Headers.

[Anthony Awtrey (tony-awtrey)]

This affects version Eucalyptus version 1.6.2.

[graziano obertelli (graziano.obertelli)]

Can you confirm that this behavior is still present in Eucalyptus 2.x? A quick check with curl seems to indicate the problem is not present in 2.x.

[Anthony Awtrey (tony-awtrey)]

I'd like to, but our development and deployment platform is Lucid 10.04 LTS. Even if it is fixed in v2.0, it does me no good until April of 2012 when we have our next scheduled upgrade. I don't have a spare cluster I install v2.0 and test the issue on.

This issue creates a problem for current boto release (and I assume other client libraries that demonstrate 408 timeout errors). Boto uses HTTP connection pooling and the extraneous text from the HEAD request stays in the connection buffer and breaks the next request that uses that connection. It took me almost two days to track this down. I hope if it is fixed in v2.0 that it can be backported and pushed to the LTS release. Right now I have a hacked boto that explicitly clears the buffer to work around this issue.

You can see the test script I submitted and follow the conversation as Mitchell Garnaat and I worked through the issue in this boto-dev thread:

 http://groups.google.com/group/boto-dev/browse_frm/thread/5191ecd996e1375d

Thanks for your help on this!

[Mitch Garnaat (mitch-garnaat)]

I just tested this against our Partner Cloud and I'm seeing the same issue there so I don't think this has been fixed yet.

[Andy Grimm (agrimm)]

This issue is now being tracked upstream at http://eucalyptus.atlassian.net/browse/EUCA-2782

Please watch that issue for further updates.