Re: Error in http.lua's chunked encoding

[David Fifield <david () bamsoftware com>]

On Mon, Aug 17, 2009 at 11:24:25PM -0300, Joao Correa wrote:
> The problem happens because the request made was a HEAD request, where
> no body exists. The following patch fixed the problem for me. Thanks!
>
> Index: http.lua
> ===================================================================
> --- http.lua  (revision 15069)
> +++ http.lua  (working copy)
> @@ -828,7 +828,7 @@
>                       ( body:match( "\n" )   and "\n" ) or nil
>  
>    -- handle chunked encoding
> -  if result.header['transfer-encoding'] == 'chunked' then
> +  if result.header['transfer-encoding'] == 'chunked' and #body > 0 then
>      local _, chunk
>      local chunks = {}
>      for _, chunk in get_chunks(body, 1, body_delim) do

This patch is fine for a quick solution but it is not correct in
general. We shouldn't just ignore it when there is no body; for example
if a response to a GET request has a chunked Transfer-Encoding and no
body (not even an empty chunk), that's a genuine error that should be
reported. In a response to pipelined requests it probably also means
that the rest of the stream is messed up.

Section 4.3 of RFC 2616 says when a response does not have a body:

        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. All 1xx (informational), 204 (no
        content), and 304 (not modified) responses MUST NOT include a
        message-body. All other responses do include a message-body, although
        it MAY be of zero length.

So you have to know whether it was a HEAD request and the status code.

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org