Bug Report #4791
Request_Client_Curl adds extra content-type header to all requests
|Assignee:||Lorenzo Pisani||% Done:|
By default, Request_Client_Curl adds a
Content-Type: application/x-www-form-urlencoded to the request headers even if the request body is empty. This can cause external requests eg to an Amazon S3 pre-signed URL to fail because the request headers do not match those used to sign the URL.
The content type header is set internally by curl when a CURLOPT_POSTFIELDS argument is present in the curl options. Therefore, this should only be set if there is a request body to be sent.
Don't set empty body on external curl requests [Fixes #4791]
When the CURLOPT_POSTFIELDS option is present, curl adds a
default Content-Type header which can be changed but not
removed, causing authentication problems with signed requests.
The option should only be set if a request body is being sent.
#1 Updated by Andrew Coulton 10 months ago
I have a fix for this at https://github.com/kohana/core/pull/402 - which is very simple, just don't set CURLOPT_POSTFIELDS if the request body is empty.
I have not been able to produce a sensible test case for this, as the behaviour happens within curl and there is no access to the curl handle from outside the request client so no way to make assertions about what headers are actually sent.
The only possible way to test that I can think of would be to make live HTTP requests, capture the CURLOPT_VERBOSE output to a temporary file and then make assertions on the temporary file content. This will obviously slow the test suite and feels a bit brittle since the format of the CURLOPT_VERBOSE output is outside our scope. I'm not sure if the test servers run a local HTTP server for testing against, or if we'd have to make an external request.
If you're particularly keen for a test, I can put together something along those lines but IMHO the fix is simple and the test would be dirty and slow...