14 ms·

URLs can be tricky and have plenty of gotchas depending on what you're trying to do. For example, the order of query params is free to change but it's still the

URLs can be tricky and have plenty of gotchas depending on what you're trying to do. For example, the order of query params is free to change but it's still the same URL. Nothing that can't be worked around with a little normalization.

Karellen 2y ago
> For example, the order of query params is free to change but it's still the same URL. Are you sure that's guaranteed by any spec? I thought an end-point would be free to treat `?a=1&b=2` and `?b=2&a=1` differently. I mean, it would be a nightmarish implementation, but I don't think it would be non-conforming?
- Piskvorrr 2y ago
  It's a mere convention: "a querystring of this type is an array of parameters, the order of which is irrelevant" - this is one of the tautological "valid except when it's not" non-rules (a surprising number of cases). Example: ?a=1&b=2&a=3 - will the server treat this to be equivalent as ?a=3&b=2&a=1 , or ?b=2&a=1 , ?b=2&a=3 , or something else entirely? You'd need to check the serverside parsing implementation to be sure - those could even be valid (and distinct) filenames FWIW. (And that's before you get to caching - "?b=2&a=1 is not to be served as a cached version of ?a=1&b=2")
  - trevor-e 2y ago
    The repeated case is something I hadn't thought of when I wrote the original comment since I would never do that so this got me curious. Looks like it _isn't_ guaranteed by any spec, and different frameworks have their own rules as you pointed out. For example, PHP will take the last duplicate param value as the "winner", and others group them into an array. While I think this would be a bad application design, it looks like swapping the order of params could result in errors in some cases. In practice though I would treat the URLs the same.
    - Piskvorrr 2y ago
      You would never do that, I wouldn't either, but in machine-to-machine API interactions, this tends to crop up - i.e. a SW stack where this implies "an array of `a` values and a scalar `b` value" sends the data to a SW stack where "last `a` wins, last `b` wins", and strange bugs ensue, as both sides insist they're doing The Right Thing :)

Karellen 2y ago

> For example, the order of query params is free to change but it's still the same URL. Are you sure that's guaranteed by any spec? I thought an end-point would be free to treat `?a=1&b=2` and `?b=2&a=1` differently. I mean, it would be a nightmarish implementation, but I don't think it would be non-conforming?

Piskvorrr 2y ago
It's a mere convention: "a querystring of this type is an array of parameters, the order of which is irrelevant" - this is one of the tautological "valid except when it's not" non-rules (a surprising number of cases). Example: ?a=1&b=2&a=3 - will the server treat this to be equivalent as ?a=3&b=2&a=1 , or ?b=2&a=1 , ?b=2&a=3 , or something else entirely? You'd need to check the serverside parsing implementation to be sure - those could even be valid (and distinct) filenames FWIW. (And that's before you get to caching - "?b=2&a=1 is not to be served as a cached version of ?a=1&b=2")
- trevor-e 2y ago
  The repeated case is something I hadn't thought of when I wrote the original comment since I would never do that so this got me curious. Looks like it _isn't_ guaranteed by any spec, and different frameworks have their own rules as you pointed out. For example, PHP will take the last duplicate param value as the "winner", and others group them into an array. While I think this would be a bad application design, it looks like swapping the order of params could result in errors in some cases. In practice though I would treat the URLs the same.
  - Piskvorrr 2y ago
    You would never do that, I wouldn't either, but in machine-to-machine API interactions, this tends to crop up - i.e. a SW stack where this implies "an array of `a` values and a scalar `b` value" sends the data to a SW stack where "last `a` wins, last `b` wins", and strange bugs ensue, as both sides insist they're doing The Right Thing :)