Description: ------------ The S3 REST API has an object copy method that is achieved through a HTTP PUT request. Rather than specifying the content in the body of the PUT request, a separate header "copy-from-source" specifies the content to copy. The "content-type" header is used in the request to set the content type of the new object on S3. Currently, HTTP_Request2_Adapter checks the length of the request body, and if it is zero, unsets the content-type header. A separate issue not affecting this request, but affecting other requests is if the content-type header is not specified, HTTP_Request_Adapter sends a default content-type of 'application/x-form- urlencoded'. For S3 requests, this should default to 'binary/octet-stream' or ideally not be set at all. What I'd like to be able to do is specify a config option on the HTTP_Request2 object that turns off the automatic setting/unsetting of the content-type and content-length headers.

I don't see a problem with automatically setting Content-Type, if you want 'binary/octet-stream' just make sure that you call setHeader(). Not setting it is a bad idea, see RFC 2616 7.2.1 > Any HTTP/1.1 message containing an entity-body SHOULD include a > Content-Type header field defining the media type of that body As for removing content-type on zero-length requests, I think I'll change this behaviour for POST and PUT requests, they already send 'Content-Length: 0' even when request body is missing, removing Content-Type there was an oversight.

Sounds good to me. For the S3 copy method (it's a weird one) there is no entity body for the PUT request, so not sending a Content-Type would not break the recommendation of RFC 2616-7.2.1. That said, it will work fine being set explicitly and I'm happy with this solution!

Patch: http://bit.ly/4DJvFo http://labs.silverorange.com/files/pear-patches/http-request2-request-16799-2009- 11-19.diff

Thanks for the patch! Fixed in release 0.5.1