<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><div class="m_-3600459991025673487WordSection1 gmail_msg"><div class="gmail_msg"><div id="m_-3600459991025673487replyquoted" class="gmail_msg"><table class="m_-3600459991025673487MsoNormalTable gmail_msg" border="0" cellspacing="0" cellpadding="0" width="100%" style="width:100.0%;background:#f4f5fb"><tbody class="gmail_msg"><tr class="gmail_msg"><td nowrap valign="top" style="padding:3.0pt 15.0pt 3.0pt 11.25pt" class="gmail_msg"><br></td><td width="100%" style="width:100.0%;padding:0in 0in 0in 0in" class="gmail_msg"><br>
</td>
</tr>
<tr class="gmail_msg">
<td nowrap valign="top" style="padding:3.0pt 15.0pt 3.0pt 11.25pt" class="gmail_msg">
<p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Verdana",sans-serif;color:black" class="gmail_msg">Message<u class="gmail_msg"></u><u class="gmail_msg"></u></span></p>
</td>
<td width="100%" style="width:100.0%;padding:0in 0in 0in 0in" class="gmail_msg">
<p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Verdana",sans-serif;color:#666666" class="gmail_msg">The core specification (<a href="http://openid.net/specs/openid-connect-core-1_0.html" class="gmail_msg" target="_blank">http://openid.net/specs/openid-connect-core-1_0.html</a>) 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).<br class="gmail_msg">
<br class="gmail_msg">
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 '+'.<br class="gmail_msg">
<br class="gmail_msg">
The scenario where this is most likely to cause a problem would be if a param value ever needed to contain a '+' character.</span></p></td></tr></tbody></table></div></div></div></div></blockquote><div><br></div><div>This is plain wrong.</div><div><br></div><div>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.</div><div><br></div><div>HTML 5, the HTML Standard, and the URL Standard all define the serialization in terms of "the application/x-www-form-urlencoded serializer":</div><div><a href="https://www.w3.org/TR/html/sec-forms.html#mutate-action-url">https://www.w3.org/TR/html/sec-forms.html#mutate-action-url</a><br></div><div><a href="https://html.spec.whatwg.org/multipage/forms.html#submit-mutate-action">https://html.spec.whatwg.org/multipage/forms.html#submit-mutate-action</a><br></div><div><a href="https://url.spec.whatwg.org/#urlsearchparams-stringification-behavior">https://url.spec.whatwg.org/#urlsearchparams-stringification-behavior</a><br></div><div>This was also true of HTML 4: <a href="https://www.w3.org/TR/html4/interact/forms.html#h-17.13.3.4">https://www.w3.org/TR/html4/interact/forms.html#h-17.13.3.4</a> that introduced the form element and the application/x-www-form-urlencoded encoding.</div><div>This has been reflected in most programming language APIs that deal with such format:</div><div>Java's java.net.URLDecoder and java.net.URLEncoder (also used to decode query in servlets  * for getParameter): <a href="https://docs.oracle.com/javase/8/docs/api/java/net/URLDecoder.html">https://docs.oracle.com/javase/8/docs/api/java/net/URLDecoder.html</a></div><div> * PHP's urlencoded and urldecode: <a href="https://secure.php.net/manual/en/function.urlencode.php">https://secure.php.net/manual/en/function.urlencode.php</a>, and parse_str <a href="https://secure.php.net/manual/en/function.parse-str.php">https://secure.php.net/manual/en/function.parse-str.php</a> and other similar query-string-based logic (e.g. $_GET)</div><div> * Python's urlparse.parse_qs and urllib.urlencoded: <a href="https://docs.python.org/2/library/urlparse.html#urlparse.parse_qs">https://docs.python.org/2/library/urlparse.html#urlparse.parse_qs</a> (or Python 3's equivalent urllib.parse.parse_qs and urllib.parse.urlencode respectively)</div><div> * .NET's System.Web.HttpUtility.UrlDecode, UrlEncode and ParseQueryString (also used for <a href="http://ASP.NET">ASP.NET</a> HttpRequest): <a href="https://msdn.microsoft.com/en-us/library/system.web.httputility.urldecode(v=vs.110).aspx">https://msdn.microsoft.com/en-us/library/system.web.httputility.urldecode(v=vs.110).aspx</a> </div><div> * Go's "net/url".QueryEscape, ParseQuery et al. <a href="https://golang.org/pkg/net/url/">https://golang.org/pkg/net/url/</a></div><div>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')))</div><div><br></div><div>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.</div></div></div>