I'm asking in generalities - why would any server not set and return headers and/or status codes? I can't think of a good reason for this. Perhaps I'm overlooking something.
The Status-Code is a required part of a HTTP Response.
By definition, the only reason for a server not to provide a Status-Line is that it is not a HTTP server.
RFC 2616, section 6: Response.
Or said in a slightly less pedant way: if it does this, the server is hopelessly buggy and you should run away from it screaming.
Status codes were introduced in HTTP/1.0 - prior to this, things were much simpler - there were no headers in the request or the response.
A request was simply like this, with no indication of the protocol version
GET /
The response would be all body, with no headers.
So it looks like you are talking to some kind of antique webserver which only speaks HTTP/0.9!
Related
Is there a way, that is compliant with http/1.1, to request the body only?
I believe http/0.9 allowed for "GET /\r\n\r\n" which returns the body only.
I am trying to future proof a PLC application that generates a hand made HTTP request. It would be very useful to not deal with the response headers.
No, there is no way to do that.
I am qurious if there is any standard method in HTTP 1.X protocol to tell there is a problem on the server during http response that started as 200 OK.
How to tell there's any error on the server if 200 OK header is already returned and we are currently sending the response body? In some standards-compilliant way.
UPD : There is a duplicate, but without a single answer (!) HTTP: error during reply after 200 OK status code.
To be specific: I can not use Content-Length for checking at response end, because the length can't be known at response start.
Additionaly, I can't cache the whole response on the server before sending (because it is too big and I will run out of memory, and it's too long to generate so the user can't wait, etc...).
There is no standard method to do what you want.
To be precise, the standard method is to buffer the response on the server, then send a 200 OK and the Content-Length, followed by the content. As stated, this does not work for you.
The only alternative I can think of, is to wrap the content in some format that makes it discoverable whether it was sent correctly. For example, you might end it with a hash or even a digital signature. But obviously, such mechanisms are not part of the HTTP standard.
As an HTTP 1.1 server, I reply to a GET request with 200 OK status code, then start sending the data to the client.
During this send, an error occurs, and I cannot finish.
I cannot send a new status code as a final status code has already been sent.
How should I behave to let the client know an error occurred and I cannot continue with this HTTP request?
I can think of only one solution: close the socket, but it's not perfect: it breaks the keep-alive feature, and no clear explanation of the error is given to the client.
The HTTP standard seems to suppose that the server already knows exactly what to reply before it starts replying.
But this is not always the case.
Examples:
I return a very large file (several GB) from disk, and I get an IO error at some point during the reading of the file.
Same example with a large DB dump.
I cannot construct my whole response in memory then send it.
The HTTP 1.1 standard helps for such usage with the chunked transfer encoding: I don't even need to know the final size before starting to send the reply.
So these usage are not excluded from HTTP 1.1.
I finally found a possible solution for this:
HTTP 1.1 Trailer headers.
In chunked encoded bodies, HTTP 1.1 allows the sender to add data after the last (empty) chunk, in the form of a block of headers.
The specification hints some use-cases like computing on the fly a md5 of the body, and send it after the body so the client can check its integrity.
I think it could be used for error reporting, even if I haven't found anything about this kind of usage.
The issues I see with this are:
this requires using chunked encoding (but it's not much of an issue)
trailers support is probably very low:
server-side (it could be bypassed by manually creating the chunked encoding, but since it's applied after the content-encoding (gzip), it would require a lot of reimplementation)
client-side (bugs fixed only in 2010 in curl for example)
and on proxies (that could then loose the trailers if not properly implemented)
I have pushed the similar question to be answered, so here you can find that there is no solution:
How to tell there's something wrong with the server during response that started as 200 OK. Fail gracefully
Does anyone know the usage of "Proxy-agent" response header ?
Proxy-Agent: is a non-standard header - it is not defined by any HTTP RFC. As a result, it should technically be X-Proxy-Agent:. If you want a definition of anything about the way that HTTP works, RFC 2616 is your bible.
Because it is non-standard, there is no definite answer to this question. At a guess, from the name of the header, it would contain the name of the HTTP proxy software that is handling the request on behalf of the User-Agent:. But, because it is non-standard, what it actually means could be something completely different.
What I can tell you is that, because it is non-standard, it is not likely to be pertinent to the way you handle the request - although it likely informs you that there is at least one proxy somewhere along the route between the client and the server.
the HTTP specification states that the Transfer-Encoding header is allowed for requests - but what error code should a server respond if it doesn't understand that given Transfer-Encoding.
As far as I know the HTTP standard doesn't cover this possibility, but maybe I have just overlooked it.
An unknown transfer-encoding should raise a HTTP error 501 "NOT IMPLEMENTED".
That's what Apache does, at least.
Also see http://argray.com/unixfaq/httpd_error_codes.shtml
Edit: pointer to the corresponding RFC section: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.2
I agree that the answer to this is non-obvious, and have followed up on the HTTP WG's mailing list.
UPDATE: Björn H. rightfully points out:
Section 3.6 of RFC 2616:
A server which receives an
entity-body with a transfer-coding it
does not understand SHOULD return
501 (Unimplemented), and close the
connection.
So it does address this already.
Mostly a personal opinion.
i always thought 5xx errors were actual programming errors, like something fell over. If a server doesnt understand the request i would say a 4xx error is a better response as the problem is with the request not so a failed process on the server. Im not sure which 4xx but there are a few so selecting one should not be hard.
A request with an invalid Transfer-Encoding for the HTTP version is malformed. Therefore, the server should respond with 400 Bad Request.
Arguably failing to understand chunked encoding ought to be a 500 Internal Server Error rather than 501, because RFC-2616 says the server MUST understand it.
However, if a server chooses not to accept requests with chunked bodies, and it wants to blame the client for this, one way to do so legally would be 411 Length Required -- since one must not use Content-Length and Transfer-Encoding at the same time, and it is not practical to send a request without either anyway.
The RFC is a bit unclear, but IMHO it should be 406 Not Acceptable.