Tcl Source Code

Currently when using http::geturl with a server that 
does not send required headers (but starts sending 
data right away) http::Event stays in state=header and 
after command returns there is effectively nothing 
received (unless by accident some line happens to look 
like HTTP-header).

This behaviour rises from missing else clause in 
http::Event (last statement is elseif).

Suggested behaviour is that if in state=header there 
is a nonempty line that does not match any of 
expressions so far that line is considered to be first 
line of data and treated as such.

This implementation can't handle requests that use -
handler option, as socket buffer can't be unread (at 
least not at script level). Also encodings have slight 
chance of misbehaviour, as line is read before socket 
has been fconfigured. That should be possible to fix 
(except -binary configuration, where carriage return 
can be lost due translation=auto). Progress callbacks 
are likely to be problematic, too, especially with 
callbacks relying on fixed chunk sizes.

But most of these problems (excluding -handler) are to 
be expected as currently you wouldn't get anything at 
all to process.

Ideally a fix would have to be compatible with -handler and also with -channel.

A server response with no status line or headers, but only a response body, is the "Simple-Response" of HTTP/0.9 and 1.0.  The relevant text of RFC 1945 Section 6 is:

   If a client sends an HTTP/1.0 Full-Request and
   receives a response that does not begin with a Status-Line, it should
   assume that the response is a Simple-Response and parse it
   accordingly. Note that the Simple-Response consists only of the
   entity body and is terminated by the server closing the connection.

Appendix A of RFC 7230 states:

   HTTP/1.1 has been designed to make supporting previous versions easy.
   A general-purpose HTTP/1.1 server ought to be able to understand any
   valid request in the format of HTTP/1.0, responding appropriately
   with an HTTP/1.1 message that only uses features understood (or
   safely ignored) by HTTP/1.0 clients.  Likewise, an HTTP/1.1 client
   can be expected to understand any valid HTTP/1.0 response.

This suggests that our HTTP/1.1 client should be able to understand a valid HTTP/1.0 "Simple-Response", even though the "Simple-Response" is not valid as a HTTP/1.1 response.  The typical origin of a "Simple-Response" is an ancient HTTP/1.0 server.

File Added - 201267: noheaders.patch