Eucalyptus

Walrus incorrectly provides content on HEAD request

Bug #844139 reported by Anthony Awtrey
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Eucalyptus
New
Undecided
Neil Soman

Bug Description

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.

Revision history for this message
Anthony Awtrey (tony-awtrey) wrote :

This affects version Eucalyptus version 1.6.2.

Revision history for this message
graziano obertelli (graziano.obertelli) wrote :

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.

Revision history for this message
Anthony Awtrey (tony-awtrey) wrote :

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!

Revision history for this message
Mitch Garnaat (mitch-garnaat) wrote :

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.

Daniel Nurmi (nurmi)
Changed in eucalyptus:
assignee: nobody → Neil Soman (neilsoman)
Revision history for this message
Andy Grimm (agrimm) wrote :

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

Please watch that issue for further updates.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.