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. Flexible request decoding helps the Consumer, by requiring the Service Provider to accept popular encodings. Flexible response decoding helps the Service Provider, by requiring the Consumer to accept popular encodings.

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.

To discuss these extensions, please use the Flexible Encoding thread in the Google Group OAuth Extensions.

Extension: Flexible Request Decoding

In an HTTP request, parameters MAY be sent in the body and/or URL query string 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.