Re: bugs in http.lua?

[David Fifield <david () bamsoftware com>]

On Sat, Dec 12, 2009 at 07:15:08PM -0700, David Fifield wrote:
> The main problem with it is that you're looking for specific values for
> strings that are allowed to vary. The response might not say "HTTP/1.1"
> but maybe "HTTP/1.0" or even "HTTP/1.2" in the future. The
> Reason-Phrases "Continue" and "OK" may be blank, in a different
> language, or nonsense; the only thing that matters is the status code.
>
> Another problem is that the code only allows a 200 status code following
> the 100. If a POST results in a 301 or a 400 or something else, that's
> what has to be reported to the caller. See what you can do to handle all
> these cases. Don't grep for something that looks like a Status-Line
> ("HTTP/1.1 200 OK") to decide when the next response begins; that way is
> incorrect even though the http library does it in other places, and it's
> not necessary here. The 100 response ends after the first "\r?\n\r?\n"
> because 100 responses aren't allowed to have a body. This is what
> section 4.3 says:

Oops, sorry, I see that you already addressed this part in
http://seclists.org/nmap-dev/2009/q4/560. The bit about "HTTP/1.1" and
"Continue" still stands.

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