[Openid-specs-ab] FW: A comment from Randy Hudson [2200661:2644405]

Thomas Broyer t.broyer at gmail.com
Tue Jan 31 14:53:50 UTC 2017


>
>
> Message
>
> The core specification (
> http://openid.net/specs/openid-connect-core-1_0.html) incorrectly
> specifies that "application/x-www-form-urlencoded" form should be used for
> encoding query param values in a *URL*. Despite its name,
> application/x-www-form-urlencoded is only for the body of an HTTP request.
> The biggest different is in how PLUS and SPACE characters are
> encoded/decoded. The examples, however, actually encode SPACE correctly in
> a URL, using %20, rather than as '+' (if form encoding format were really
> being used).
>
> In the examples that use POST to send params,
> application/x-www-form-urlencoded makes sense, but the examples show %20
> used to encode SPACE, rather than '+'.
>
> The scenario where this is most likely to cause a problem would be if a
> param value ever needed to contain a '+' character.
>

This is plain wrong.

Neither RFC3986 nor RFC7230 define a specific encoding for key-value pairs
in the query string. Also, "+" being a "reserved" character means that "+"
and "%2B" are not (necessarily) equivalent.

HTML 5, the HTML Standard, and the URL Standard all define the
serialization in terms of "the application/x-www-form-urlencoded
serializer":
https://www.w3.org/TR/html/sec-forms.html#mutate-action-url
https://html.spec.whatwg.org/multipage/forms.html#submit-mutate-action
https://url.spec.whatwg.org/#urlsearchparams-stringification-behavior
This was also true of HTML 4:
https://www.w3.org/TR/html4/interact/forms.html#h-17.13.3.4 that introduced
the form element and the application/x-www-form-urlencoded encoding.
This has been reflected in most programming language APIs that deal with
such format:
Java's java.net.URLDecoder and java.net.URLEncoder (also used to decode
query in servlets  * for getParameter):
https://docs.oracle.com/javase/8/docs/api/java/net/URLDecoder.html
 * PHP's urlencoded and urldecode:
https://secure.php.net/manual/en/function.urlencode.php, and parse_str
https://secure.php.net/manual/en/function.parse-str.php and other similar
query-string-based logic (e.g. $_GET)
 * Python's urlparse.parse_qs and urllib.urlencoded:
https://docs.python.org/2/library/urlparse.html#urlparse.parse_qs (or
Python 3's equivalent urllib.parse.parse_qs and urllib.parse.urlencode
respectively)
 * .NET's System.Web.HttpUtility.UrlDecode, UrlEncode and ParseQueryString
(also used for ASP.NET HttpRequest):
https://msdn.microsoft.com/en-us/library/system.web.httputility.urldecode(v=vs.110).aspx

 * Go's "net/url".QueryEscape, ParseQuery et al.
https://golang.org/pkg/net/url/
One notable exception is ECMAScript's decodeURIComponent which won't turn a
"+" into a space (encodeURIComponent will turn a space into %20, but will
also turn a + into %2B) so those have to be pre-processed (e.g.
decodeURIComponent(value.replace(/\+/g, '%20')))

So: it's OK to use application/x-www-form-urlencoded when talking about the
query-string encoding of key-value pairs; and spaces can be encoded either
as %20 or +, while a + needs to be encoded as %2B.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170131/f05813f1/attachment.html>


More information about the Openid-specs-ab mailing list