6 ms·

This is actually used. I get it all the time. The only thing very interesting about 402 is that it is so close to 400 - meaning some committee must have though

This is actually used. I get it all the time. The only thing very interesting about 402 is that it is so close to 400 - meaning some committee must have thought this would be important for the future (of the internet). I guess history didn't pan out this way. On GCP: https://cloud.google.com/resource-manager/docs/core_errors https://cloud.google.com/resource-manager/docs/core_errors PAYMENT_REQUIRED (402) dailyLimitExceeded402: A daily budget limit set by the developer has been reached. quotaExceeded402: The requested operation requires more resources than the quota allows. Payment is required to complete the operation. user402: The requested operation requires some kind of payment from the authenticated user.

jerf 7y ago
"meaning some committee must have thought this would be important for the future (of the internet)." Have a read down the entire standard [1] with an eye to that. There's a number of codes that are useless (some deprecated), and a number of other codes that I feel uncomfortable calling useless, but compared to how the web evolved, certainly aren't working the way the initial designers intended. 406 "Not Acceptable", for instance, is for when the client sent up Accept-* headers that don't match anything the server offers. That's technically usable, but content negotiation ultimately didn't play as big a part of the web as RFC 7231's text suggests the authors thought it would. There's a lot of response codes squeezed on both sides by the fact that 1. they're too underspecified to be really useful (yes, it's great that you can return 402 payment required, but where is the browser supposed to go from there?) and 2. had they been specified enough to use at the time they were specified, they would have been utterly wrong. I don't think there's any way to square that circle at a standards level. [1]: https://tools.ietf.org/html/rfc7231#section-6.2 https://tools.ietf.org/html/rfc7231#section-6.2
- 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.
- duxup 7y ago
  >406 "Not Acceptable" That is fairly amusing considering the sort of nonsensical popularity of that phrase (at least in the US).
- jlokier 7y ago
  > it's great that you can return 402 payment required, but where is the browser supposed to go from there? Don't forget the browser is allowed to return a HTML page with the 402 error, telling the browser, user, or other user-agent exactly what to do. For example the 402 error page could contain a payment form to be filled in, or other instructions to the user. Or even a button: "Yes I agree to pay $10 to see the article".
  - jerf 7y ago
    The entire point of returning a status code, at least in theory, would be to not simply be practically-semantically indistinguishable from a 200. In practice, if you try to return a 402 with an HTML page explaining how to pay, you'll quickly revert that because you'll break some percentage of HTTP clients (not browsers, but other ones) that will try to do "something" with 402, even if it's just assuming "well, it's a 4xx so it's basically a 404", and you'll return a 200 for that page. On the one hand, it isn't necessarily that many clients that will blow up, but on the other hand, you'll observe that no clients will be confused by the 200, so the engineering pressures are pretty consistent here, which is why everybody ends up in the same place. In theory, if you read the standard, you ought to be able to return a 402, and use content-negotiation to decide whether to return it in a human-readable format, or some rich selection of machine-readable formats, and you ought to be able to annotate it with several dimensions of somewhat overlapping information about exactly how to cache it and exactly what conditions should cause the cache to be expired, including some specification of the HTTP-standard authorization techniques available, etc. etc.... in practice, pretty much every individual element in that collection only sorta works, and trying to do all of them at once essentially impossible at scale, and you'll return a 200 page with HTML and expect the client to pick up the pieces, and if you do offer a JSON view, while you may honor the negotiation stuff you'll probably also allow a querystring or form parameter to ask for JSON too because you can't count on the people writing clients to even know what headers are.... and libraries often make them somewhat less convenient to work with than form parameters, since everybody needs those. And you probably won't "content negotiate" at all, but just have entirely separate URLs for your human stuff and your official "REST API", because most people who try to get clever and make your human website URLs also be the "REST API" pretty quickly discover it's not worth the effort.
- sillysaurusx 7y ago
  I am totally going to throw a 406 Not Acceptable in production now. Thank you for the idea. Not sure how I’ll find an excuse, but I have years to plan. 406 Unacceptable would have made it more useful for today’s tumultuous world.
  - squeaky-clean 7y ago
    Error 406: Not Acceptable User address "123 Main st, Scunthorpe" includes unacceptable language.
- dlbucci 7y ago
  I thought Not Acceptable was a counterpart to 202 Accepted, meaning, "we could not accept this request for processing"? I've also seen it used in place of 400, which is definitely a misuse, but overall, I think it's a very unclear label...
  - icebraining 7y ago
    Well, you're supposed to read the docs, not just guess from the label. But I agree that they could have done better; maybe "No acceptable response".
- DaveInTucson 7y ago
  I think the problem is that "payment required" is an issue that's better dealt with in a layer higher up the protocol stack. One can simply respond with the appropriate redirection code to a login/signup page (or whatever) when the client attempts to access a page where "payment is require" (just like any other authentication/authorization issue).
  - tjoff 7y ago
    That is not what the user would want though. Getting nothing is adequate when nothing exist. Pretending it was something else is just confusing at best.
Techies4Trump 7y ago
I don't think that was the original intended use. I believe the intention of this status code was to allow the application to negotiate payment using some not-yet-invented payment technology. The browser would presumably shell out to some kind of local wallet or bank website to authorize the payment, all in a split second without the user noticing. What you're describing is the typical paywall type page where a user is asked for payment.
- dang 7y ago
  This is a perfectly legit comment but can you please not use a trollish username on HN? It ends up trolling every thread it posts to, and whether they're right to or not, some people are inevitably going to be provoked by it. If you'd like to change the account name, we'd be happy to help with that at hn@ycombinator.com. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20trollish%20username&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
  - klez 7y ago
    Funny thing is, I wouldn't have noticed the account name if you didn't point it out.
    - dang 7y ago
      Others would, though. That's the problem with the long tail: it only takes one or two provokeables to end up with an offtopic mess.
      - lightedman 7y ago
        Looks like you're the only one provoked by the name, dang.
        dang 7y ago
        No, someone emailed to complain about it.
jszymborski 7y ago
It made it into Project Xanadu's 17 rules, so I imagine this was likely in the minds of most people when the internet was starting out. > 15. Every Xanadu service provider can charge their users at any rate they choose for the storage, retrieval and publishing of documents. https://en.wikipedia.org/wiki/Project_Xanadu#Original_17_rules https://en.wikipedia.org/wiki/Project_Xanadu#Original_17_rul...
bbody 7y ago
I use 402 in one of my web applications at the payment step, but it is kind of just arbitrary as I use the accompanying error message on the frontend.

jerf 7y ago

"meaning some committee must have thought this would be important for the future (of the internet)." Have a read down the entire standard [1] with an eye to that. There's a number of codes that are useless (some deprecated), and a number of other codes that I feel uncomfortable calling useless, but compared to how the web evolved, certainly aren't working the way the initial designers intended. 406 "Not Acceptable", for instance, is for when the client sent up Accept-* headers that don't match anything the server offers. That's technically usable, but content negotiation ultimately didn't play as big a part of the web as RFC 7231's text suggests the authors thought it would. There's a lot of response codes squeezed on both sides by the fact that 1. they're too underspecified to be really useful (yes, it's great that you can return 402 payment required, but where is the browser supposed to go from there?) and 2. had they been specified enough to use at the time they were specified, they would have been utterly wrong. I don't think there's any way to square that circle at a standards level. [1]: https://tools.ietf.org/html/rfc7231#section-6.2 https://tools.ietf.org/html/rfc7231#section-6.2

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.
duxup 7y ago
>406 "Not Acceptable" That is fairly amusing considering the sort of nonsensical popularity of that phrase (at least in the US).
jlokier 7y ago
> it's great that you can return 402 payment required, but where is the browser supposed to go from there? Don't forget the browser is allowed to return a HTML page with the 402 error, telling the browser, user, or other user-agent exactly what to do. For example the 402 error page could contain a payment form to be filled in, or other instructions to the user. Or even a button: "Yes I agree to pay $10 to see the article".
- jerf 7y ago
  The entire point of returning a status code, at least in theory, would be to not simply be practically-semantically indistinguishable from a 200. In practice, if you try to return a 402 with an HTML page explaining how to pay, you'll quickly revert that because you'll break some percentage of HTTP clients (not browsers, but other ones) that will try to do "something" with 402, even if it's just assuming "well, it's a 4xx so it's basically a 404", and you'll return a 200 for that page. On the one hand, it isn't necessarily that many clients that will blow up, but on the other hand, you'll observe that no clients will be confused by the 200, so the engineering pressures are pretty consistent here, which is why everybody ends up in the same place. In theory, if you read the standard, you ought to be able to return a 402, and use content-negotiation to decide whether to return it in a human-readable format, or some rich selection of machine-readable formats, and you ought to be able to annotate it with several dimensions of somewhat overlapping information about exactly how to cache it and exactly what conditions should cause the cache to be expired, including some specification of the HTTP-standard authorization techniques available, etc. etc.... in practice, pretty much every individual element in that collection only sorta works, and trying to do all of them at once essentially impossible at scale, and you'll return a 200 page with HTML and expect the client to pick up the pieces, and if you do offer a JSON view, while you may honor the negotiation stuff you'll probably also allow a querystring or form parameter to ask for JSON too because you can't count on the people writing clients to even know what headers are.... and libraries often make them somewhat less convenient to work with than form parameters, since everybody needs those. And you probably won't "content negotiate" at all, but just have entirely separate URLs for your human stuff and your official "REST API", because most people who try to get clever and make your human website URLs also be the "REST API" pretty quickly discover it's not worth the effort.
sillysaurusx 7y ago
I am totally going to throw a 406 Not Acceptable in production now. Thank you for the idea. Not sure how I’ll find an excuse, but I have years to plan. 406 Unacceptable would have made it more useful for today’s tumultuous world.
- squeaky-clean 7y ago
  Error 406: Not Acceptable User address "123 Main st, Scunthorpe" includes unacceptable language.
dlbucci 7y ago
I thought Not Acceptable was a counterpart to 202 Accepted, meaning, "we could not accept this request for processing"? I've also seen it used in place of 400, which is definitely a misuse, but overall, I think it's a very unclear label...
- icebraining 7y ago
  Well, you're supposed to read the docs, not just guess from the label. But I agree that they could have done better; maybe "No acceptable response".
DaveInTucson 7y ago
I think the problem is that "payment required" is an issue that's better dealt with in a layer higher up the protocol stack. One can simply respond with the appropriate redirection code to a login/signup page (or whatever) when the client attempts to access a page where "payment is require" (just like any other authentication/authorization issue).
- tjoff 7y ago
  That is not what the user would want though. Getting nothing is adequate when nothing exist. Pretending it was something else is just confusing at best.

Techies4Trump 7y ago

I don't think that was the original intended use. I believe the intention of this status code was to allow the application to negotiate payment using some not-yet-invented payment technology. The browser would presumably shell out to some kind of local wallet or bank website to authorize the payment, all in a split second without the user noticing. What you're describing is the typical paywall type page where a user is asked for payment.

dang 7y ago
This is a perfectly legit comment but can you please not use a trollish username on HN? It ends up trolling every thread it posts to, and whether they're right to or not, some people are inevitably going to be provoked by it. If you'd like to change the account name, we'd be happy to help with that at hn@ycombinator.com. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20trollish%20username&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
- klez 7y ago
  Funny thing is, I wouldn't have noticed the account name if you didn't point it out.
  - dang 7y ago
    Others would, though. That's the problem with the long tail: it only takes one or two provokeables to end up with an offtopic mess.
    - lightedman 7y ago
      Looks like you're the only one provoked by the name, dang.
      - dang 7y ago
        No, someone emailed to complain about it.

jszymborski 7y ago

It made it into Project Xanadu's 17 rules, so I imagine this was likely in the minds of most people when the internet was starting out. > 15. Every Xanadu service provider can charge their users at any rate they choose for the storage, retrieval and publishing of documents. https://en.wikipedia.org/wiki/Project_Xanadu#Original_17_rules https://en.wikipedia.org/wiki/Project_Xanadu#Original_17_rul...

bbody 7y ago

I use 402 in one of my web applications at the payment step, but it is kind of just arbitrary as I use the accompanying error message on the frontend.