4 ms·

> 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

> 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.
- kortilla 7y ago
  You do know browsers render 404 error pages, right?
  - hansvm 7y ago
    Most modern browsers do.
    - behnamoh 7y ago
      > The HTTP 418 I'm a teapot client error response code indicates that the server refuses to brew coffee because it is a teapot. I wonder how FF/Chrome would react to this!
      - Izkata 7y ago
        By just rendering it: https://httpstat.us/418 https://httpstat.us/418
      - snek 7y ago
        https://www.google.com/teapot https://www.google.com/teapot
  - jerf 7y ago
    Yes. 200, 301, and 404 are top-tier status codes that even the simplest system can't help but handle in some sensible manner. In the second tier you have the necessary support for partial content and basic content negotiation. After that is when it gets a lot more complicated. The fact that "browsers render 404 pages" won't save you when you try to get "clever", err, I mean, "standards compliant" and serve a complicated HTTP page out on 402. It probably won't confuse browsers, which will probably just render the page and leave the user oblivious a 402 occurred, which is precisely why I included "(not browsers, but other ones)". Browsers are forced to march together in some semblance of lock step. When you step out into the heterogeneous world programming language APIs, "convenience" code written on top of those APIs, frameworks written on top of that convenience code, internal libraries written on top of those frameworks... yeah... you can't get very many complicated semantics through that sort of pipeline. And that's not a terribly unrealistic pipeline, unfortunately.
tyingq 7y ago
That seems reasonable to me. Browsers ended up dealing with 401 and "Basic Auth", in a semi-standard way, for example. "Payment required" isn't substantially different. More complex for sure, but the context shared seems sufficient.
SergeAx 7y ago
I saw dozens of websites with elaborative 404 pages, like including search form, or even returning site search results with context of requested page, splitting URI to keywords. I see how it is implementable with 402 status as well.

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.

kortilla 7y ago
You do know browsers render 404 error pages, right?
- hansvm 7y ago
  Most modern browsers do.
  - behnamoh 7y ago
    > The HTTP 418 I'm a teapot client error response code indicates that the server refuses to brew coffee because it is a teapot. I wonder how FF/Chrome would react to this!
    - Izkata 7y ago
      By just rendering it: https://httpstat.us/418 https://httpstat.us/418
    - snek 7y ago
      https://www.google.com/teapot https://www.google.com/teapot
- jerf 7y ago
  Yes. 200, 301, and 404 are top-tier status codes that even the simplest system can't help but handle in some sensible manner. In the second tier you have the necessary support for partial content and basic content negotiation. After that is when it gets a lot more complicated. The fact that "browsers render 404 pages" won't save you when you try to get "clever", err, I mean, "standards compliant" and serve a complicated HTTP page out on 402. It probably won't confuse browsers, which will probably just render the page and leave the user oblivious a 402 occurred, which is precisely why I included "(not browsers, but other ones)". Browsers are forced to march together in some semblance of lock step. When you step out into the heterogeneous world programming language APIs, "convenience" code written on top of those APIs, frameworks written on top of that convenience code, internal libraries written on top of those frameworks... yeah... you can't get very many complicated semantics through that sort of pipeline. And that's not a terribly unrealistic pipeline, unfortunately.

tyingq 7y ago

That seems reasonable to me. Browsers ended up dealing with 401 and "Basic Auth", in a semi-standard way, for example. "Payment required" isn't substantially different. More complex for sure, but the context shared seems sufficient.

SergeAx 7y ago

I saw dozens of websites with elaborative 404 pages, like including search form, or even returning site search results with context of requested page, splitting URI to keywords. I see how it is implementable with 402 status as well.