-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow encoding of null values in application/x-www-form-urlencoded
.
#732
Comments
After "searching the literature" I found a similar issue here: #427 |
That this is about This was discussed in #469 and I stand by #469 (comment). If you want null, omit the key. I can appreciate that it's difficult to migrate existing software though. But also, in theory there's nothing stopping servers from interpreting a URL's query however they wish. They just can't claim to support |
To a certain extent, I think your comment is fair, but where that breaks down is:
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 Either way, I don't personally have a strong opinion about it, but it would be convenient and makes the I would like to know, before this specification, was |
application/x-www-form-urlencoded
.
The key is that the standard only has a single model: a string-to-string(s) multimap. Each entry in this multimap had a string key, and its value is one or more strings. This model does not support:
In particular, this model is not by itself capable of representing string-keyed maps to arbitrary values in your target language. The value space for each entry is much more limited. Now. You can build more complicated models on top of the standard's model! You should just do so in a layered fashion, and do so while acknowledging you are going beyond any shared web standard and thus are going to need to do a lot of outreach and consensus building among all consumers/producers you want to interoperate with. In particular, browsers have no need for a more complicated model, and so won't participate. It's easiest if you constrain your model to just one client/server pair, but maybe you want it to expand to "all client/server pairs using a specific library", or even set of collaborating libraries. Examples of ways you could layer on top of the spec's model include:
Etc. The main idea is that you have a limited space to work with, when you layer on top of the standard's model. So it'll take some work to get people to agree. |
@domenic I'm personally fine with that model, but the reality is a fairly predominant pattern of people interpreting Since I think we prefer to follow the standard, my only hope for those users was to propose some kind of change to the standard. From my point of view, introducing layered interpretations doesn't help that much when everyone has their own bespoke concept of what a layer should be like - the entire point of standards is to standardise the approach so we don't end up with people building N different ways of representing null values etc. Again, I don't have a strong opinion about it, but this is the pain point and I'm just bringing it up and starting the discussion on behalf of the affected users/developers. |
Well, there's already a layer you're imposing on top---whatever layer is doing the "[]" stuff, and is translating lists-of-single-string-values into just string values. That isn't in this standard. My suggestion is to work with whatever community is responsible for that layer, to extend it to support additional semantics that you'd like. That commmunity isn't really related to this repo though, so here is probably not the right place. This repo is fully about the model I outlined above, since that model is the one browsers use. |
Fair enough. I think what people are asking for is some level of standardisation of some of those layers. Otherwise as a maintainer of a shared implementation, we can't really introduce bespoke layering without being opinionated (and as you said, not following a standard). Is there any case where browsers actually do need to specify null values? e.g. |
No, |
I mean, if servers got together and agree on additional semantics I could see compatible extensions to I haven't seen sufficient interest in that though and I suspect most existing usage is fairly entrenched and unable to change. And yeah, given that browsers would not be the primary stakeholders but more a beneficiary this doesn't seem like the right place to drive that, but I'd be open to it if we got a group of people together that's somewhat representative of that space. |
I think the original semantics ( |
Thanks @ioquatix for bringing this up from Grape and @domenic and @annevk for your comments! Y'all make a ton of sense, even though I think you are too focused on browsers, which are like people, a bit unpredictable at times. In contrast, I think most API developers that were not forced into using My conclusion is that it was nice when the implementation allowed nulls in a non-ambiguous way In Grape! What @ioquatix was suggesting is to restore that, but I agree that we're extending the spec by doing so. We plan to cleanly deprecate that behavior, tell our users that it's now undefined, and call it a day. |
Is this why some systems get confused when someone actually has a name "null"? i.e. no. way to differentiate between Some funny examples: |
I found a lot of NULLs in URLs, https://www.wired.com/2015/11/null/ 🤷 |
If we treated pairs with no key-value delimiter as having a
In other words, we would not be able to skip strings of empty pair delimiters ( To illustrate why we would need to do that: I have an API which allows identifying each key-value pair by its position (i.e. an index) and supports index-based operations such as inserting pairs at a particular location, replacing a region of pairs, removing a particular pair, or changing the key/value of a particular pair. Now consider the URL
But if you replace the key with the empty string, something interesting happens:
Since empty strings of delimiters are usually skipped entirely, we must insert an Currently this is fine, because the presence or not of the
And to say that this initial I'm not opposed to that (in fact, the |
Does any framework in existence actually do that? |
Do what? Interpret a plain Not that I know of - that's why I said it would be a significant departure, but it is also a logical consequence of saying that a missing key-value delimiter means a |
While I understand order of elements has semantic meaning, the degenerate case of |
url/url.bs
Lines 2933 to 2934 in fdaa0e5
Some systems want to encode null values.
e.g.
differently from empty strings, e.g.
I wonder if we can amend this rule to allow optional special interpretation of keys without
=
separators to indicate that the value isnull
.Consider adding the wording:
Or something to that effect.
See ruby-grape/grape#2298 and rack/rack#1696 for more details/discussion over the past 2 years.
The text was updated successfully, but these errors were encountered: