httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: svn commit: r354108 - /httpd/httpd/branches/2.2.x/STATUS
Date Mon, 05 Dec 2005 18:19:02 GMT
William A. Rowe, Jr. wrote:
> But the obvious tangle becomes - do we return T-E chunked - and is that
> a valid header as a HEAD response with no body?

 From 2616 4.3,

    For response messages, whether or not a message-body is included with
    a message is dependent on both the request method and the response
    status code (section 6.1.1). All responses to the HEAD request method
    MUST NOT include a message-body, even though the presence of entity-
    header fields might lead one to believe they do.

I read this that the T-E entity-header field should be forwarded.

Under 4.4

    2.If a Transfer-Encoding header field (section 14.41) is present and
      has any value other than "identity", then the transfer-length is
      defined by use of the "chunked" transfer-coding (section 3.6),
      unless the message is terminated by closing the connection.

so the length is not known to a HEAD response using T-E.

    3.If a Content-Length header field (section 14.13) is present, its
      decimal value in OCTETs represents both the entity-length and the
      transfer-length. The Content-Length header field MUST NOT be sent
      if these two lengths are different (i.e., if a Transfer-Encoding
      header field is present). If a message is received with both a
      Transfer-Encoding header field and a Content-Length header field,
      the latter MUST be ignored.

so this suggests that technically they may both be sent IF the two len's
are identicial.  But we already understand that an intermediate hostile
proxy can warp the response, breaking the client's results.  Of course
the same hostile proxy can perform any number of sorts of corruption.

But the only way we know we will send the same T-E and C-L values is to
determine the C-L as a result of piping the results through the output
filters to the network stack.  Your patch suggests we should ignore that
potential issue.

Finally still in 4.4 we find

    All HTTP/1.1 applications that receive entities MUST accept the
    "chunked" transfer-coding (section 3.6), thus allowing this mechanism
    to be used for messages when the message length cannot be determined
    in advance.

    Messages MUST NOT include both a Content-Length header field and a
    non-identity transfer-coding. If the message does include a non-
    identity transfer-coding, the Content-Length MUST be ignored.

so clearly the Microsoft Update application violates RFC 2616 and should
be tagged as such, by adding an http10 proxy entry (we can add this, leaving
it commented out, in our example config.)

Someday everyone will understand that fast dynamic content, and predetermined
transmission size are incompatible goals, and the goal of T-E: chunked will
be pervasive enough that those who violate the RFC can simply be ignored.


View raw message