You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When sending the access token in the HTTP request entity-body, the
client adds the access token to the request-body using the
"access_token" parameter. The client MUST NOT use this method unless
all of the following conditions are met:
o The HTTP request entity-header includes the "Content-Type" header
field set to "application/x-www-form-urlencoded".
o The entity-body follows the encoding requirements of the
"application/x-www-form-urlencoded" content-type as defined by
HTML 4.01 [W3C.REC-html401-19991224].
o The HTTP request entity-body is single-part.
According to RFC6750, if the access token is sent via the entity body, seems content-type have to be checked equal to application/x-www-form-urlencoded, is this intended for this library?
The text was updated successfully, but these errors were encountered:
As far as I understand this library, it is only concerned with the server part, where as the cited rule is one that clients have to obey. The first thing that came to my mind is that with these requirements, you can't easily put the bearer token in a form with a file upload. I'd think the main reason of this rule is to restrict what kinds of body parsing a bearer token parser has to support, and to motivate webmasters to build file uploads in a way where the server can validate the token before even deciding whether to start reading the body.
I think the highlighted rule's impact on the server side is just "you may safely ignore any body whose Content-Type isn't application/x-www-form-urlencoded."
https://tools.ietf.org/html/rfc6750#section-2.2
2.2. Form-Encoded Body Parameter
When sending the access token in the HTTP request entity-body, the
client adds the access token to the request-body using the
"access_token" parameter. The client MUST NOT use this method unless
all of the following conditions are met:
o The HTTP request entity-header includes the "Content-Type" header
field set to "application/x-www-form-urlencoded".
o The entity-body follows the encoding requirements of the
"application/x-www-form-urlencoded" content-type as defined by
HTML 4.01 [W3C.REC-html401-19991224].
o The HTTP request entity-body is single-part.
According to RFC6750, if the access token is sent via the entity body, seems content-type have to be checked equal to application/x-www-form-urlencoded, is this intended for this library?
The text was updated successfully, but these errors were encountered: