3 ms·

As someone who has written his own HTTP client, I think that the author greatly exaggerates the difficulty in doing so. The reason being that he assumes that al

As someone who has written his own HTTP client, I think that the author greatly exaggerates the difficulty in doing so. The reason being that he assumes that all clients are meant to be completely fault tolerant. The client that I wrote was used for only a handful of websites all of which had 0 quirks found to date. However, I still dont get his examples: > For example: Headers can span multiple lines. This is by design: "Header fields can be extended over multiple lines by preceding each extra line with at least one SP or HT" [1]. The example he gives does not have the whitespace in front, but that is a particular variation that isnt too hard to deal with. > The length of a response body is indicated by a mixture of the response code, the Transfer-Encoding header, Content-Length header, Connection header (and the request method). It has been my experience so far that if there is a content-length header, then that is the length of the body end of story. The only case in which I resort to using the connection header is the one in which there is no transfer-encoding or content-length. I still have never come across a case in which I needed to know the request method to be able to parse the result. > Get messages can have a body, but not every server knows this. I didnt know that. I would like to see more information about this too. Still, this is irrelevant when writing a client. In conclusion, this article points out that there may be a lot of variations between implementation of the HTTP protocol, but I would have liked to know of the actual servers and conditions which cause them to behave that way. [1]http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html

salgernon 13y ago
There have probably been more 1 off servers written in the period of 1993 to 2000 than in the past three years. If you never encounter one of those older servers, consider yourselves lucky. If you expect to support every server out here, including the ones attached to crapoy webcams and toaster ovens, then you should be prepared for exact what the OP is talking about. I don't mean to pick on your response, but there have been a lot of comments in this thread that amounts to "it's not that hard", when the reality is quite different. And when proxies come in to play, the matrix of pain is multiplied.
__david__ 13y ago
> > Get messages can have a body, but not every server knows this. > I didnt know that. I would like to see more information about this too. I had an argument with a co-worker about this. The spec is a bit ambiguous about GET requests with bodies. Section 4.3 of RFC 2616 [1] says: A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests. A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request. Section 9.3 [2] is the section about GET requests and it never mentions request bodies (they call them entities in section 9) at all. Section 9.8 [3], "TRACE" says: A TRACE request MUST NOT include an entity. So, 4.3 can be interpreted as: the spec does not disallow it, so it's allowed. But it can also be interpreted as: it isn't explicitly allowed in the GET section, so it isn't allowed. I think the wording is bad enough that it can be interpreted either way, especially because some methods explicitly allow request bodies (PUT, POST) and some explicitly disallow them (TRACE). My personal opinion is that if they meant to disallow bodies in GETs then they would have said "...does not explicitly allow sending..." in section 4.3. [1] https://tools.ietf.org/html/rfc2616#section-4.3 https://tools.ietf.org/html/rfc2616#section-4.3 [2] https://tools.ietf.org/html/rfc2616#section-9.3 https://tools.ietf.org/html/rfc2616#section-9.3 [3] https://tools.ietf.org/html/rfc2616#section-9.8 https://tools.ietf.org/html/rfc2616#section-9.8

salgernon 13y ago

There have probably been more 1 off servers written in the period of 1993 to 2000 than in the past three years. If you never encounter one of those older servers, consider yourselves lucky. If you expect to support every server out here, including the ones attached to crapoy webcams and toaster ovens, then you should be prepared for exact what the OP is talking about. I don't mean to pick on your response, but there have been a lot of comments in this thread that amounts to "it's not that hard", when the reality is quite different. And when proxies come in to play, the matrix of pain is multiplied.

__david__ 13y ago

> > Get messages can have a body, but not every server knows this. > I didnt know that. I would like to see more information about this too. I had an argument with a co-worker about this. The spec is a bit ambiguous about GET requests with bodies. Section 4.3 of RFC 2616 [1] says: A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests. A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request. Section 9.3 [2] is the section about GET requests and it never mentions request bodies (they call them entities in section 9) at all. Section 9.8 [3], "TRACE" says: A TRACE request MUST NOT include an entity. So, 4.3 can be interpreted as: the spec does not disallow it, so it's allowed. But it can also be interpreted as: it isn't explicitly allowed in the GET section, so it isn't allowed. I think the wording is bad enough that it can be interpreted either way, especially because some methods explicitly allow request bodies (PUT, POST) and some explicitly disallow them (TRACE). My personal opinion is that if they meant to disallow bodies in GETs then they would have said "...does not explicitly allow sending..." in section 4.3. [1] https://tools.ietf.org/html/rfc2616#section-4.3 https://tools.ietf.org/html/rfc2616#section-4.3 [2] https://tools.ietf.org/html/rfc2616#section-9.3 https://tools.ietf.org/html/rfc2616#section-9.3 [3] https://tools.ietf.org/html/rfc2616#section-9.8 https://tools.ietf.org/html/rfc2616#section-9.8