This wiki is no longer active and is left here for historical purposes. Please visit oauth.net for up-to-date information.
View
 

FlexibleDecoding

This version was saved 10 years, 4 months ago View current version     Page history
Saved by PBworks
on October 4, 2007 at 2:47:08 pm
 

Here are two related extensions to OAuth, one each for requests and responses. These extensions make it easier to implement OAuth using popular HTTP software.

 

OAuth Core requires encodings that aren't exactly what popular software HTTP does. For example, an OAuth Consumer built with the Jakarta Commons HTTP client won't conform to OAuth, because it won't encode request parameters exactly as specified in OAuth section 5.1. Such a Consumer will probably work just fine, because most HTTP server software supports the same encodings. The purpose of these extensions is merely to encourage this happy result.

 

The request decoding extension gives more freedom to the Consumer, by requiring the Service Provider to accept a variety of encodings. The response decoding extension gives more freedom to the Service Provider, by requiring the Consumer to accept a variety of encodings.

 

Extension: Flexible Request Decoding

 

In an HTTP request, parameters MAY be sent in the body as a document of MIME type application/x-www-form-urlencoded that conforms to HTML 4.01 section 17.13.4.1. The Service Provider MUST accept such parameters (as well as parameters that conform to OAuth Core).

 

In an OAuth Authorization header (OAuth section 5.4.1), parameter names and values MAY be percent-encoded in any way that conforms to RFC 3986 section 2.1. However, the characters '"' (double quote), '=' (equal sign), ',' (comma) and '+' (plus sign) within a parameter name or value MUST be percent-encoded. The Service Provider MUST accept such parameters (as well as parameters that conform to OAuth Core).

 

In a PLAINTEXT signature (OAuth section 9.4.1), signature components MAY be percent-encoded in any way that conforms to RFC 3986 section 2.1. However, the characters '&' and '+' within a signature component MUST be percent-encoded. The Service Provider MUST accept this encoding (as well as OAuth Core Parameter Encoding), when validating a PLAINTEXT signature.

 

Text MUST be encoded as UTF-8 octets before percent-encoding them (consistent with OAuth section 5.1).

 

The Service Provider MUST ignore the case of percent-encoded bytes; that is, it must treat 'A' through 'F' as equivalent to 'a' through 'f' respectively. The Service Provider SHOULD accept any percent-encoded byte, including %20 (space) and percent-encoded unreserved characters.

 

Extension: Flexible Response Decoding

 

In an HTTP response, parameters MAY be sent in the body as a document of MIME type application/x-www-form-urlencoded that conforms to HTML 4.01 section 17.13.4.1. The Consumer MUST accept such parameters (as well as parameters that conform to OAuth Core).

 

In an OAuth WWW-Authorization header (OAuth section 5.4.2), parameter names and values MAY be percent-encoded in any way that conforms to RFC 3986 section 2.1. However, the characters '"' (double quote), '=' (equal sign), ',' (comma) and '+' (plus sign) within a parameter name or value MUST be percent-encoded. The Consumer MUST accept such parameters (as well as parameters that conform to OAuth Core).

 

Text MUST be encoded as UTF-8 octets before percent-encoding them (consistent with OAuth section 5.1).

 

The Consumer MUST ignore the case of percent-encoded bytes; that is, it must treat 'A' through 'F' as equivalent to 'a' through 'f', respectively. The Consumer SHOULD accept any percent-encoded byte, including %20 (space) and percent-encoded unreserved characters.

Comments (0)

You don't have permission to comment on this page.