Re: [whatwg/url] Allow encoding of null values. (Issue #732)

To a certain extent, I think your comment is fair, but where that breaks down is:

1. Encoding arrays with embedded null values. e.g. `encode("x", [1, null, 2]) => x[]=1&x[]&x[]=2`
2. Explicitly specifying something is null: perhaps the remote end assumes a default value unless otherwise specified, and if you can't explicitly specify null, the default is assumed (so the absence of a key doesn't imply null).
3. Round-tripping the exact data structure. It's impossible to serialise `{x: null}` and deserialise the same data on the remote end.

With the proposed changes, it's possible to support these use cases. Otherwise, for most other cases that I'm aware of, simply omitting the value is sufficient.

I made this issue because when we standardised Rack (v3) to follow the current `application/x-www-form-urlencoded` standard, downstream systems were broken. So, to your point - "migrate existing software" can be tricky.

Either way, I don't personally have a strong opinion about it, but it would be convenient and makes the `application/x-www-form-urlencoded` format more useful and complete. Either way, having a specific documented stance on allowing or disallowing this would help guide users of URL query parsers what they should and shouldn't expect, and where they might like to reach for something more elaborate (e.g. JSON). For example, the alternative of this proposal is to explicitly call out treating query values like `x` itself as null, as invalid.

I would like to know, before this specification, was `application/x-www-form-urlencoded` specified anywhere? It does seem to me that some languages are adopting `x` itself as a defacto representation of `{x: null}`. Some research from 2 years ago: https://github.com/rack/rack/issues/1696#issuecomment-661699610

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/732#issuecomment-1370761878
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/issues/732/1370761878@github.com>

Received on Wednesday, 4 January 2023 10:43:20 UTC