Re: Misc review notes for draft-18 p1

On 27/01/2012 4:56 a.m., Willy Tarreau wrote:
>
> 3.3. Message Body
>
>>    The length of the message-body is determined by one of the following
>>    (in order of precedence):
>>
>>    1.  Any response to a HEAD request and any response with a status
>>        code of 100-199, 204, or 304 is always terminated by the first
>>        empty line after the header fields, regardless of the header
>>        fields present in the message, and thus cannot contain a message-
>>        body.
> Now that we've included the CONNECT method in the spec, I think it makes
> sense to define whether it has a body or not in case of success. I've
> found myself sometimes adding "Content-length: 0" as well as huge values
> in the past on some CONNECT requests to help interoperability with broken
> proxies, as well as "Connection: close" on these similar requests. Obviously
> the implementations were faulty but a faulty implementation often results
> from ambiguous specs.
>
> Could we suggest that as a first rule, a 200 response to a CONNECT request
> implies an infinite content length (I don't like that very much since it's
> false), or that it has no message body and that the connection is immediately
> switched to a tunnel ?
>
>     0. Any response with a status code of 200 to a CONNECT request does not
>        contain any message-body and immediately switches to a tunnel (Section
>        6.9 of [Part2]).
>
> Also, since I've seen some implementations send "Content-length: 0" on
> CONNECT requests (which I happened to mimmick once), I'm realizing that
> it's not always obvious what to send on responses where no content is
> expected. Would it make sense to insist on the fact that it is not
> necessary to send "Content-length: 0" on messages which do not have a
> body by the rules above ?

+1 to avoiding Content-Length corruption tricks. But ...

I have a client in a situation which requires relaying CONNECT requests 
between proxies. We can safely negotiate chunking between two 1.1 
proxies to enable keep-alive optimizations on these, if it were to be 
defined as having no body at all that would break.

The same problem may also apply to Upgrade for unknown protocols. When 
the upgraded protocol is completed, having the handlers close the 
connection and cycle through TCP TIME_WAIT instead of cleanly releasing 
it for re-use by the outer layer protocol again would be a major annoyance.


>
>
> 3.5. Message Parsing Robustness
>
>>    Likewise, although the line terminator for the start-line and header
>>    fields is the sequence CRLF, we recommend that recipients recognize a
>>    single LF as a line terminator and ignore any CR.
> Does this mean that CR CR CR CR CR CR LF should be interpreted as a single
> LF ? It kinds of scares me on the risk of smuggling attacks. I'd rather
> suggest :
>
>      ... we recommend that recipients recognize a single LF as a line
>      terminator and ignore the optional preceeding CR. Messages containing
>      a CR not followed by an LF MUST be rejected.

+1.

>
>>    When a server listening only for HTTP request messages, or processing
>>    what appears from the start-line to be an HTTP request message,
>>    receives a sequence of octets that does not match the HTTP-message
> Wouldn't "does not *exactly* match" be better ? I'm used to find
> crappy requests in my logs which are blocked but which some not-so-lazy
> implementations would let pass (eg: multiple SP).

+1. I've just finished my second round of convincing peoples not to pad 
out the end of the line to a nice round length with SP.

> A.1.2 Keep-Alive Connections
>
>>    Clients are also encouraged to consider the use of Connection: keep-
>>    alive in requests carefully; while they can enable persistent
>>    connections with HTTP/1.0 servers, clients using them need will need
>>    to monitor the connection for "hung" requests (which indicate that
>>    the client ought stop sending the header),
> I know a number of people who use the term "the header" to designate all
> the headers section. I must say that when I read this sentence, it was
> unclear to me upon first reading that the intent was in fact to stop
> sending "Connection: keep-alive" in subsequent requests, as it can also
> be understood as "stop sending the headers as long as the connection
> hangs" (which does not make sense).
>
> I'd suggest the following change :
>
> -   the client ought stop sending the header),
> +   the client ought stop using this header in further communications with
> +   the server),

Nit:
     s/ought/ought to/


AYJ

Received on Monday, 30 January 2012 00:01:05 UTC