note 18037 deleted from function.fsockopen by danbrown

Note Submitter: info at TAKETHISOUT dot ski-info-online dot com ---- This is a "gotcha" that "got me" and discusses the careful use of HTTP/1.1 over HTTP/1.0 I had a script that suffered dreadful performance and return Hex values amongst the correct data. This was eventually traced to my inclusion of HTTP/1.1 in the line which read: -- CODE (watch wrap) -- $request = "GET $document" . "?" . "$query" . " HTTP/1.1\r\n"; $request .= "Host: $myServer\r\n\r\n"; -- CODE -- By sending a HTTP/1.1 request it declares that it is willing to 'speak' HTTP/1.1, of course, but there are some aspects of HTTP/1.1 that make it necessary to handle the socket differently from HTTP/1.0. In the RFC 2616, Section 3.6 defines: [...] All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer-coding, [...] This was the cause of the extraneous HEX values being displayed. Regards the loss of performance, this is also due to using HTTP/1.1, which defaults to having keepalive on until you tell it to close the connection, or it times out. Therefore the socket was being kept open by the script. Simply changing the line in the script to HTTP/1.0 completely fixed the problem. Speaking with one of the members in PHP-dev his words were: [Comment from Hartmut Holzgraefe] "I stumbled over the same 'chunked' problem not to long ago as a rule of thumb: never use HTTP/1.1 unless you really know that you have to, claiming to be a HTTP/1.0 client is no problem." I have posted this as it was something I found very difficult to debug as there is actually nothing wrong with the script. This sort of problem often requires an in depth knowledge of an area that most developers would not have or consider. I would doubt that many, in any, who are reading this have ever read the HTTP RFC 2616 (I doubt also that it is a rivetting read :)) I hope this helps any future developers who are considering the use of high level socket connections with HTTP/1.1.