{"id":3740,"date":"2013-11-10T20:33:04","date_gmt":"2013-11-10T19:33:04","guid":{"rendered":"http:\/\/blog.visisoft.de\/yalst\/?p=812"},"modified":"2015-05-28T23:52:19","modified_gmt":"2015-05-28T21:52:19","slug":"null-and-undefined-values-in-a-type-safe-uri-query","status":"publish","type":"post","link":"https:\/\/www.yalst.de\/en\/null-and-undefined-values-in-a-type-safe-uri-query\/","title":{"rendered":"Encoding of null and undefined in a type-safe URI query"},"content":{"rendered":"

Encoding of null and undefined in a type-safe URI query<\/h4>
<\/div><\/div><\/div>\n\n

TL;DR<\/h4>\n

When transferring variables in the query part of an URI, encode the JavaScript value null<\/code>\u00a0in\u00a0key=null<\/code> as ?key<\/code>. Distinguish between undefined<\/code>, null<\/code> and an empty string by omitting the key altogether for undefined<\/code> and appending an equal\u00a0sign for the latter. I.e.\u00a0?key=<\/code>\u00a0stands for\u00a0key=\"\"<\/code>. Use the\u00a0URI.js<\/a>\u00a0as helper library for\u00a0URI query extraction and composition.<\/p>\n

The Problem<\/h4>\n

The standard way of encoding of data in the query part of an URI<\/a> in the format
\n\"?key1=value1&key2=value2...\"<\/code> is created for the purpose of submitting a HTML form<\/em> via a HTTP GET request (with content type application\/x-www-form-urlencoded<\/code>).<\/p>\n

In general the types of the variables encoded in this way are not preserved.<\/p>\n

Imagine for instance that booleans<\/em> could get encoded as true<\/code> and false<\/code> making then indistinguishable from strings with those values.<\/p>\n

Type-safe URI query for null<\/code> , undefined<\/code> and \"\"<\/code><\/h4>\n

Outside the use for HTML forms the syntactic format of the query part of a URI is largely by convention.
\nFrom the URI rfc<\/a>:<\/p>\n

\n

The query component is indicated by the first question mark (“?”) character and terminated by a number sign (“#”) character or by the end of the URI.<\/p>\n<\/blockquote>\n

http_URL = \"http:\" \"\/\/\" host [ \":\" port ] [ abs_path [ \"?\" query ] \"#\" fragment ]<\/code><\/pre>\n
Thus the query part can contain anything except the number sign (“#”).<\/p>\n
URIs containing query components like ?key<\/code> and ?key=<\/code> for a variable key<\/code> are valid URIs. This can be leveraged to fix type safety for null<\/code> values.<\/p>\n
The problem however is how these formats are interpreted by different query component parsers.<\/p>\n
Note:<\/strong> This discussion just applies to cases where you are forced to resort to the HTTP GET query component to transmit variables which can be null<\/code> or undefined<\/code>. In general it is advised to use a more suitable format like JSON<\/a> for more type-safe en\/decoding of your data.<\/small><\/p>\n
Choosing the right query component builder\/parser library<\/h4>\n
URI.js<\/h5>\n
Values of null<\/code> or undefined<\/code> are invariant<\/em> with respect to URI query component encoding-decoding.<\/p>\n
\/\/ composing\r\nURI.buildQuery({keyN: null, keyU: undefined, keyS: \"\"});  \/\/ <\/code><\/pre>\n
Node.js, jQuery-Purl<\/h5>\n
Node.js’ url module<\/a> as well as the combination of jQuery<\/a> and Purl<\/a> coalesce null<\/code>, undefined<\/code> and \"\"<\/code> into ?key=<\/code>. which in turn always get decoded as empty string.<\/p>\n
\/\/\/\/\/ Node.js \/\/\/\/\/\r\nurl = require('url');\r\n\/\/ composing\r\nurl.format({query: {keyN: null, keyU: undefined, keyS: \"\"}});  \/\/ <\/code><\/pre>\n
\/\/ composing with jQuery\r\n$.param({keyN: null, keyU: undefined, keyS: \"\"}); \/\/ <\/code><\/pre>\n