9 ms·

IME HTTP 406 is not as uncommon as you imply. Ask a Java/JAX-RS service for accept: foo/bar and 406 Not Acceptable is what you'll probably get.

by sk5t 7y ago

detaro 7y ago
But there's relatively little value in that being an extra code: How often do you encounter systems that do something with the fact that it is 406 and not a generic 400 and e.g. switch their content type? I think that's what the parent is referring to.
- sk5t 7y ago
  I agree you probably won't find a lot of systems that will automatically "fix" a 406 or 422, or that have an ordered list of more than one media type they are willing to accept in followup requests. OTOH I do think it's useful to be able to convey and log this type of error in a standard way. 406 can be more or less interesting than 400 retrospectively. Also, isn't HTTP 503 just about the same as 500 as far as your garden variety client is concerned--even if it's technically plausible some client, somewhere, might want to more aggressively seek out a stale cached result for a 503?
  - unilynx 7y ago
    503 could still be useful if combined with the Retry-After header but I wonder if any generic client code/library uses it in that way. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re...
  - sterlind 7y ago
    503 is useful for me as a human. If I see a 500 on an internal site I assume they're throwing exceptions; if I see 503 I know the service is gone and I should redeploy.
- jerf 7y ago
  Yes; the idea behind 406 and the whole content negotiation thing seemed to be that clients and servers would somehow notice they didn't negotiate a common representation and then do "something" sensible in response to that, not that it would be essentially treated no differently from any other 4xx error. Quite a lot of the web would just ignore the mismatch and serve the resource up anyhow with whatever Content-Type the server wanted, and, honestly, that seems to work OK. It's not that it may not be an error in some sense, it's that the standard has this rich set of specific errors that seems as if it's coming from some parallel universe where the web evolved much differently. And it's not that there is no overlap with our real universe, it's just that if you read the standard and kind of do a postmodernism-style analysis of what the authors must have thought was important, what you get doesn't much resemble the real-world web of today. Or in the case of HTTP 1.1, even the real world web of the time.
- skissane 7y ago
  > But there's relatively little value in that being an extra code For the developer of the client, there is value in that it tells you to start your troubleshooting by looking at the "Accept" header. By contrast, a generic 400 doesn't give you that hint; maybe there will be something in the response headers or body to give you that hint, maybe there won't be.
- tannhaeuser 7y ago
  One hypothetical use case I can think of going forward is sites/content that only work with JavaScript enabled, and that you must request with "Accept: application/html" to signal you're willing to execute their code, as opposed to "text/html" to signal you're not specifically going to switch on JavaScript for their trackers, and expect at least basic static content to show up. Of course, "application/html" needs to be registered at IANA first, and then should be used on most of today's aggregator sites.
  - mstade 7y ago
    You'd have to also change all clients to not execute JavaScript in text/html, if you want application/html to have any bite. Another option, perhaps more likely to have an effect, is to have clients with no JavaScript enabled to include a parameter with the accept type, e.g. `text/html;profile=no-js` or some such. Servers that don't recognize the parameter can just ignore it, and servers that do recognize it can serve up a no-js response. Any client that doesn't know this parameter will just functions as normal. No need to invent a new content type.
Macha 7y ago
422 Unprocessable Entity is also relatively commonly used in the enterprise Java world for validation errors, despite technically only being for WebDAV
lloeki 7y ago
Also mostly automatically returned by Rails

IME HTTP 406 is not as uncommon as you imply. Ask a Java/JAX-RS service for accept: foo/bar and 406 Not Acceptable is what you'll probably get.

by sk5t 7y ago

IME HTTP 406 is not as uncommon as you imply. Ask a Java/JAX-RS service for accept: foo/bar and 406 Not Acceptable is what you'll probably get.

detaro 7y ago

But there's relatively little value in that being an extra code: How often do you encounter systems that do something with the fact that it is 406 and not a generic 400 and e.g. switch their content type? I think that's what the parent is referring to.

sk5t 7y ago
I agree you probably won't find a lot of systems that will automatically "fix" a 406 or 422, or that have an ordered list of more than one media type they are willing to accept in followup requests. OTOH I do think it's useful to be able to convey and log this type of error in a standard way. 406 can be more or less interesting than 400 retrospectively. Also, isn't HTTP 503 just about the same as 500 as far as your garden variety client is concerned--even if it's technically plausible some client, somewhere, might want to more aggressively seek out a stale cached result for a 503?
- unilynx 7y ago
  503 could still be useful if combined with the Retry-After header but I wonder if any generic client code/library uses it in that way. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re...
- sterlind 7y ago
  503 is useful for me as a human. If I see a 500 on an internal site I assume they're throwing exceptions; if I see 503 I know the service is gone and I should redeploy.
jerf 7y ago
Yes; the idea behind 406 and the whole content negotiation thing seemed to be that clients and servers would somehow notice they didn't negotiate a common representation and then do "something" sensible in response to that, not that it would be essentially treated no differently from any other 4xx error. Quite a lot of the web would just ignore the mismatch and serve the resource up anyhow with whatever Content-Type the server wanted, and, honestly, that seems to work OK. It's not that it may not be an error in some sense, it's that the standard has this rich set of specific errors that seems as if it's coming from some parallel universe where the web evolved much differently. And it's not that there is no overlap with our real universe, it's just that if you read the standard and kind of do a postmodernism-style analysis of what the authors must have thought was important, what you get doesn't much resemble the real-world web of today. Or in the case of HTTP 1.1, even the real world web of the time.
skissane 7y ago
> But there's relatively little value in that being an extra code For the developer of the client, there is value in that it tells you to start your troubleshooting by looking at the "Accept" header. By contrast, a generic 400 doesn't give you that hint; maybe there will be something in the response headers or body to give you that hint, maybe there won't be.
tannhaeuser 7y ago
One hypothetical use case I can think of going forward is sites/content that only work with JavaScript enabled, and that you must request with "Accept: application/html" to signal you're willing to execute their code, as opposed to "text/html" to signal you're not specifically going to switch on JavaScript for their trackers, and expect at least basic static content to show up. Of course, "application/html" needs to be registered at IANA first, and then should be used on most of today's aggregator sites.
- mstade 7y ago
  You'd have to also change all clients to not execute JavaScript in text/html, if you want application/html to have any bite. Another option, perhaps more likely to have an effect, is to have clients with no JavaScript enabled to include a parameter with the accept type, e.g. `text/html;profile=no-js` or some such. Servers that don't recognize the parameter can just ignore it, and servers that do recognize it can serve up a no-js response. Any client that doesn't know this parameter will just functions as normal. No need to invent a new content type.

Macha 7y ago

422 Unprocessable Entity is also relatively commonly used in the enterprise Java world for validation errors, despite technically only being for WebDAV

lloeki 7y ago

Also mostly automatically returned by Rails