5 ms·

>So I’ve decided to try a blanket ban for this site: no unauthorised query strings. His site returns (I think incorrectly) a 414 if a request includes a query

>So I’ve decided to try a blanket ban for this site: no unauthorised query strings. His site returns (I think incorrectly) a 414 if a request includes a query string. If this protest is meant to advocate for the user, who presumably wasn't able to manage that string in the first place, why would you penalize them for it being there? Why not just use it as a cue to tell users how they can make this decision themselves (e.g. through browser tools)?

bryanrasmussen 5mo ago
It's been years but I seem to remember there was a version of PLSQL server pages that would return 500 if you tried to pass in an unknown query string.
jampekka 5mo ago
"You could argue that I’m abusing 414 URI Too Long. I respond that it’s funnier this way. Other options I considered were: 400 Bad Request, the generic client error code, which is correct but boring; 402 Payment Required, and honestly if you want to pay me to make a particular URL with query string work, I’m open to it; 404 Not Found, but it’s too likely to have side effects, and it doesn’t convey the idea that the request was malformed, which is what I’m going for; and 303 See Other with no Location header, which is extremely uncommon these days but legitimate. Or at least it was in RFC 2616 (“The different URI SHOULD be given by the Location field in the response”), but it was reworded in 7231 and 9110 in a way that assumes the presence of a Location header (“… as indicated by a URI in the Location header field”), while 301, 302, 307 and 308 say “the server SHOULD generate a Location header field”. Well, I reckon See Other with no Location header is fair enough. But URI Too Long was funnier." https://chrismorgan.info/no-query-strings?foo https://chrismorgan.info/no-query-strings?foo
- 1shooner 5mo ago
  Also from the 414 page: >Complain to whoever gave you the bad link, and ask them to stop modifying URLs, because it’s bad manners. It's ironic that an error response so blatantly violating the robustness principle is throwing shade about bad manners.
  - wizzwizz4 5mo ago
    The robustness principle is itself bad manners, in plenty of contexts. If I deliver packages by throwing them at the customer, I really want a customer to tell me "hey, don't throw packages at me!" before I attempt to lob something fragile and breakable, or something heavy at someone fragile and breakable. Otherwise, how am I supposed to learn that I'm doing anything wrong?
    - ikiris 5mo ago
      This is the point this has delved into internet crankery.
      - wizzwizz4 5mo ago
        No, it's a fairly uncontroversial take. See https://en.wikipedia.org/wiki/Robustness_principle#Criticism https://en.wikipedia.org/wiki/Robustness_principle#Criticism and the "See also" section.
  - btilly 5mo ago
    Opinions vary on how good an idea the robustness principle is. That is why, for example, the XML standard requires a conforming validator to throw an error on invalid XML. In our modern world, the robustness principle has become an invitation to security bugs, and vendor lock-in. Edge cases snuck through one system on robustness, then trigger unfortunate behavior when they hit a different system. Two systems tried to do something reasonable on an ambiguous case, but did it differently, leading to software that works on one, failing to work on the other.
    - 1shooner 5mo ago
      I generally agree, but I don't think XML is the best example. Getting HTML out of XML is considered to have been the right move isn't it? I was pro-XHTML2 at the time but in retrospect, have we suffered much for not sending webpage validation errors to end users?
- ollien 5mo ago
  I don't think it's an abuse, RFC9110 defines 414 as a response for "refusing to service the request because the target URI is longer than the server is willing to interpret". Since adding a query string involves only adding characters, this seems fine; there's no stipulation as far as I can tell that all pages a server hosts must adhere to the same length. I'd be curious if any well-known clients interpret it that way though, and make caching decisions based on it. As far as I know, they shouldn't. Obviously it's against the spirit of the thing, but I don't think it's wrong per-se.
  - lucketone 5mo ago
    If the goal is to be misleading, but technically correct, it hits the bullseye
    - ollien 5mo ago
      When the goal is "the funniest way", I think that's a hit :)
  - chrismorgan 5mo ago
    I reckon it is still an abuse. I am willing to interpret longer target URIs… so long as they don’t contain a question mark. /no-query-strings is longer than /?.
    - zymhan 5mo ago
      The standard doesn't say that you must accept all URIs up to a certain length. You're allowed to decide, based on context, what is "too long". That is to say, you're allowed to have a double standard. And I love this sort of stuff, thanks for sharing.
- thayne 5mo ago
  You could also redirect to the url with the query string dropped.
  - chrismorgan 5mo ago
    But then it’s barely a protest.

bryanrasmussen 5mo ago

It's been years but I seem to remember there was a version of PLSQL server pages that would return 500 if you tried to pass in an unknown query string.

jampekka 5mo ago

"You could argue that I’m abusing 414 URI Too Long. I respond that it’s funnier this way. Other options I considered were: 400 Bad Request, the generic client error code, which is correct but boring; 402 Payment Required, and honestly if you want to pay me to make a particular URL with query string work, I’m open to it; 404 Not Found, but it’s too likely to have side effects, and it doesn’t convey the idea that the request was malformed, which is what I’m going for; and 303 See Other with no Location header, which is extremely uncommon these days but legitimate. Or at least it was in RFC 2616 (“The different URI SHOULD be given by the Location field in the response”), but it was reworded in 7231 and 9110 in a way that assumes the presence of a Location header (“… as indicated by a URI in the Location header field”), while 301, 302, 307 and 308 say “the server SHOULD generate a Location header field”. Well, I reckon See Other with no Location header is fair enough. But URI Too Long was funnier." https://chrismorgan.info/no-query-strings?foo https://chrismorgan.info/no-query-strings?foo

1shooner 5mo ago
Also from the 414 page: >Complain to whoever gave you the bad link, and ask them to stop modifying URLs, because it’s bad manners. It's ironic that an error response so blatantly violating the robustness principle is throwing shade about bad manners.
- wizzwizz4 5mo ago
  The robustness principle is itself bad manners, in plenty of contexts. If I deliver packages by throwing them at the customer, I really want a customer to tell me "hey, don't throw packages at me!" before I attempt to lob something fragile and breakable, or something heavy at someone fragile and breakable. Otherwise, how am I supposed to learn that I'm doing anything wrong?
  - ikiris 5mo ago
    This is the point this has delved into internet crankery.
    - wizzwizz4 5mo ago
      No, it's a fairly uncontroversial take. See https://en.wikipedia.org/wiki/Robustness_principle#Criticism https://en.wikipedia.org/wiki/Robustness_principle#Criticism and the "See also" section.
- btilly 5mo ago
  Opinions vary on how good an idea the robustness principle is. That is why, for example, the XML standard requires a conforming validator to throw an error on invalid XML. In our modern world, the robustness principle has become an invitation to security bugs, and vendor lock-in. Edge cases snuck through one system on robustness, then trigger unfortunate behavior when they hit a different system. Two systems tried to do something reasonable on an ambiguous case, but did it differently, leading to software that works on one, failing to work on the other.
  - 1shooner 5mo ago
    I generally agree, but I don't think XML is the best example. Getting HTML out of XML is considered to have been the right move isn't it? I was pro-XHTML2 at the time but in retrospect, have we suffered much for not sending webpage validation errors to end users?
ollien 5mo ago
I don't think it's an abuse, RFC9110 defines 414 as a response for "refusing to service the request because the target URI is longer than the server is willing to interpret". Since adding a query string involves only adding characters, this seems fine; there's no stipulation as far as I can tell that all pages a server hosts must adhere to the same length. I'd be curious if any well-known clients interpret it that way though, and make caching decisions based on it. As far as I know, they shouldn't. Obviously it's against the spirit of the thing, but I don't think it's wrong per-se.
- lucketone 5mo ago
  If the goal is to be misleading, but technically correct, it hits the bullseye
  - ollien 5mo ago
    When the goal is "the funniest way", I think that's a hit :)
- chrismorgan 5mo ago
  I reckon it is still an abuse. I am willing to interpret longer target URIs… so long as they don’t contain a question mark. /no-query-strings is longer than /?.
  - zymhan 5mo ago
    The standard doesn't say that you must accept all URIs up to a certain length. You're allowed to decide, based on context, what is "too long". That is to say, you're allowed to have a double standard. And I love this sort of stuff, thanks for sharing.
thayne 5mo ago
You could also redirect to the url with the query string dropped.
- chrismorgan 5mo ago
  But then it’s barely a protest.