Forcing content-type to 'application/octet-stream' breaks SQS requests.

[obmarg]

I've been trying to get aiobotocore working with SQS, but was getting errors because the content-type being sent with the request was always set to application/octet-stream when SQS requires application/x-www-form-urlencoded.

I've managed to track this down to these lines https://github.com/jettify/aiobotocore/blob/master/aiobotocore/endpoint.py#L105-L112 that hard-code application/octet-stream. I assume these were needed somehow for S3, but they stop the usual botocore content-type code from working. As far as I can tell, the content-type would usually be set in https://github.com/boto/botocore/blob/082a8b8e564b12500ff3de4d048f89d56d33d67d/botocore/vendored/requests/models.py#L460

I've tried removing the application/octet-stream hard coding here and it does seem to fix SQS. I haven't thoroughly tested it though.

[jettify]

Thanks for report! There reason for hard coding content-type was that in old version aiohttp there was no way to skip it. aiohttp simply added this header before sending request. When botocore calculates signature, content type is not present but added later, this leads to 403 error due to wrong signature.

New aiohttp has a way to skip auto generated headers aio-libs/aiohttp#507 so I need update aiobotocore to use this features.

I have never tested aiobotocore with SQS (only with s3), I glad to hear that it is working :)

[alanc10n]

Obmarg's patch appears to work with SQS but breaks S3 (I get a SignatureDoesNotMatch error on S3 PutObject operations).

[jettify]

@obmarg @alanc10n I have dropped hard coded content-type (f70cc48), new version should work for both: SQS and S3. Could you tests new version?

[obmarg]

This seems to have fixed SQS support - thanks!