requests / requests-oauthlib

OAuthlib support for Python-Requests!
https://requests-oauthlib.readthedocs.org/
ISC License
1.71k stars 422 forks source link

Fix for #437 - remove erroneous charset param from Content-Type header #438

Closed metadaddy closed 2 years ago

metadaddy commented 3 years ago

The WHATWG URL Standard unambiguously defines the application/x-www-form-urlencoded format, its parsing and encoding (which includes UTF-8, but applies additional steps). Consequently, no charset is required, or indeed permitted, with the application/x-www-form-urlencoded content type, and supplying one causes issues with some authorization servers.

subukris commented 3 years ago

Changes look good.

coveralls commented 3 years ago

Coverage Status

Coverage remained the same at 90.164% when pulling 2a2ef2e670d11ee943d98044f548f0a24e27f8ba on metadaddy:remove-charset into 46f886ccb74652fc9c850ece960edcf2bce765a5 on requests:master.

metadaddy commented 3 years ago

Test failures do not appear to be related to this patch.

prplecake commented 2 years ago

Would love to see this get merged, bringing requests-oauthlib into compliance with the spec.

A lot of services seem to silently accept the extra and erroneous data at the end of the Content-Type header, but it should be on the Oauth2 libraries implementing the spec to maintain compliance, and not on the Oauth2 providers.

jtroussard commented 2 years ago

Would love to see this get merged, bringing requests-oauthlib into compliance with the spec.

A lot of services seem to silently accept the extra and erroneous data at the end of the Content-Type header, but it should be on the Oauth2 libraries implementing the spec to maintain compliance, and not on the Oauth2 providers.

Noted. Some of us are working on getting the pipeline up to date, providing a good foundation to bring in contributions again. Will keep an eye on this PR. TY.

JonathanHuot commented 2 years ago

LGTM