Here are two related extensions, one each for requests and responses. They permit using popular HTTP software to implement OAuth.

Technically, OAuth core doesn't allow this: it requires a very specific encoding which is similar but not identical to what popular software HTTP does. For example, an OAuth Consumer built with popular HTTP client software probably 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 HTTP server software usually supports these encodings. The purpose of these extensions is merely to bless this happy outcome.

Extension: Flexible Request Encoding

In an HTTP request, parameters MAY be sent as a form data set, as specified by HTML 4 section 17.13.3. The Service Provider MUST accept such parameters, in the URL query string or request body or both.

In an OAuth Authorization header (OAuth section 5.4.1), parameter names and values MAY be percent-encoded as specified by RFC 3986 section 2.1. The characters '"' (double quote), '=' (equal sign) and ',' within a parameter name or value MUST be percent-encoded. The Service Provider MUST accept such parameters.

In a PLAINTEXT signature (OAuth section 9.4.1), signature components MAY be percent-encoded as specified by RFC 3986 section 2.1. The character '&' within a signature component MUST be percent-encoded . The Service Provider MUST accept this 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 Encoding

In an HTTP response, parameters MAY be sent in the body as a document of MIME type application/x-www-form-urlencoded, as specified by HTML 4.01 section 17.13.4.1. The Consumer MUST accept such parameters.

In an OAuth WWW-Authorization header (OAuth section 5.4.2), parameter names and values MAY be percent-encoded as specified by RFC 3986 section 2.1. The characters '"' (double quote), '=' (equal sign) and ',' within a parameter name or value MUST be percent-encoded. The Consumer MUST accept such parameters.

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.