4 ms·

> HTTP status codes are only meant for the application layer itself. You seem to be using a strange definition of "application", but assuming you mean "transpo

> HTTP status codes are only meant for the application layer itself. You seem to be using a strange definition of "application", but assuming you mean "transport" — I mean, this is obviously not true, right? If you sent a perfectly semantically valid HTTP request for a resource that doesn't exist on the remote, that's a 404. But by your logic, you're saying it should be a 200, because there wasn't a failure in (essentially) nginx or the HTTP library of your application server? HTTP is a transport designed for a specific type of application (document-oriented resources) and its status codes (and lots of other things) reflect that initial coupling, so it's always gonna be a pain when you swap out the application (to a credit card processing service or whatever) and have to think about how the status code mapping will work. And you can certainly "cheat" and say that every request that doesn't crash the server is 200 OK, I guess, but that's pretty clearly not what the Hyper Text Transfer Protocol wants you to do. Its set of status codes clearly reflect details of the underlying application.

parliament32 7y ago
Transport is TCP/UDP/etc. HTTP is part of the application layer, see https://en.wikipedia.org/wiki/OSI_model https://en.wikipedia.org/wiki/OSI_model and https://en.wikipedia.org/wiki/Application_layer https://en.wikipedia.org/wiki/Application_layer. >If you sent a perfectly semantically valid HTTP request for a resource that doesn't exist on the remote Requesting a path (via the application layer) that doesn't exist is a client error, hence the 4XX. But, say, if your website has a search bar and a client searches for "blahblah-thisdoesntexist" and gets no results, the webpage should return a 200 (the request was valid: the client sent form data to an existing resource and it was processed successfully) with something like "no results found" in the body -- because the search function itself is above the application layer. This is what I mean about "is the CC is authorized or not" being above the application layer. >Its set of status codes clearly reflect details of the underlying application. This is where I think you're wrong: HTTP status codes reflect the result of the HTTP request itself, not the next application in the chain, if one exists. This can also be expressed if we look lower down the chain. If my HTTP request gave me a 404, should an error be shown in the TCP stack? Well no, because TCP doesn't know or care about HTTP, as far as it's concerned the TCP connection is established and happy. Likewise, in this example, the API HTTP stack doesn't care about whether the data was a CC or something else or what the result was: as far as the HTTP stack is concerned, some JSON got passed in and parsed properly, and some output got sent back, and everything went well so "200".
- sagichmal 7y ago
  > OSI I understand OSI, but it's not a useful model in this circumstance, because it draws no distinction between the HTTP layer and the business logic served over HTTP. The complexities of that interface is what we're talking about. > HTTP status codes reflect the result of the HTTP request itself, not the next application in the chain, if one exists. Let's say I request /robotz.txt and I get 404 Not Found. How do you maintain that 404 is a result of "the HTTP request itself" and not the HTTP server handing the request to the component that looks on the filesystem (or in the cache, or in MongoDB, or...) and not finding the resource?

parliament32 7y ago

Transport is TCP/UDP/etc. HTTP is part of the application layer, see https://en.wikipedia.org/wiki/OSI_model https://en.wikipedia.org/wiki/OSI_model and https://en.wikipedia.org/wiki/Application_layer https://en.wikipedia.org/wiki/Application_layer. >If you sent a perfectly semantically valid HTTP request for a resource that doesn't exist on the remote Requesting a path (via the application layer) that doesn't exist is a client error, hence the 4XX. But, say, if your website has a search bar and a client searches for "blahblah-thisdoesntexist" and gets no results, the webpage should return a 200 (the request was valid: the client sent form data to an existing resource and it was processed successfully) with something like "no results found" in the body -- because the search function itself is above the application layer. This is what I mean about "is the CC is authorized or not" being above the application layer. >Its set of status codes clearly reflect details of the underlying application. This is where I think you're wrong: HTTP status codes reflect the result of the HTTP request itself, not the next application in the chain, if one exists. This can also be expressed if we look lower down the chain. If my HTTP request gave me a 404, should an error be shown in the TCP stack? Well no, because TCP doesn't know or care about HTTP, as far as it's concerned the TCP connection is established and happy. Likewise, in this example, the API HTTP stack doesn't care about whether the data was a CC or something else or what the result was: as far as the HTTP stack is concerned, some JSON got passed in and parsed properly, and some output got sent back, and everything went well so "200".

sagichmal 7y ago
> OSI I understand OSI, but it's not a useful model in this circumstance, because it draws no distinction between the HTTP layer and the business logic served over HTTP. The complexities of that interface is what we're talking about. > HTTP status codes reflect the result of the HTTP request itself, not the next application in the chain, if one exists. Let's say I request /robotz.txt and I get 404 Not Found. How do you maintain that 404 is a result of "the HTTP request itself" and not the HTTP server handing the request to the component that looks on the filesystem (or in the cache, or in MongoDB, or...) and not finding the resource?