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 that's not excactly 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 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 (regardless of whether they conform to OAuth Core), 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 (regardless of whether they conform to OAuth Core).

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 (regardless of whether it conforms to OAuth Core).

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 (regardless of whether they conform to OAuth Core).

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 (regardless of whether they 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.