RE: [NSE] NSE HTTP library

["Thomas Buchanan" <TBuchanan () thecompassgrp net>]

> -----Original Message-----
> From: Sven Klemm [mailto:sven () c3d2 de] 
> Sent: Thursday, January 31, 2008 9:43 AM
> To: Fyodor
> Cc: nmap-dev () insecure org; Thomas Buchanan
> Subject: Re: [NSE] NSE HTTP library
>
> Fyodor wrote:
> > My only lingering concern is the issue of multiple header fields of
> > the same name.  Sven had a pretty convincing rationale for using the
> > comma separated list as described in the HTTP 1.1 RFC at
> > http://tools.ietf.org/html/rfc2616#section-4.2 .  While parsing the
> > WWW-Authenticate fields returned by IIS may be harder using the
> > comma-separated list approach, I worry that putting in our hack just
> > for that may lead to other problems if/when we find behavior which
> > depends on the CSL handling.
> >
> > Maybe we can just make the HTTP Auth script a bit smarter with its
> > parsing--even if that means special casing some auth type 
> keywords and
> > the like.
> >
> > Or am I missing a good reason for dumping the CSL behavior?
>
> You are right. As some servers might send the header comma-separated
> the script would have to handle both situations to work under all
> circumstances. I changed the code to separate them by comma again.
> I've also adjusted the HTTP Auth script to handle this.
>
> I adjusted the header handling so that multiline headers are now
> properly handled. Earlier versions ignored those lines.
>
> You can now also set arbitrary headers for the http.get() function
> e.g.: http.get(host, port, '/', {header={Authorization="Basic
> YWRtaW46C"}})
>
> This way you can also overwrite the User-Agent or the Host used in the
> GET request.
>
> Cheers,
> Sven

Sounds good to me.  I'll try and get some testing on your changes in the
next day or so, but one thing I noticed in your patch  is that the
get_url() function in http.lua doesn't pass the options variable along
to get().

I've got some other ideas on how to improve the HTTP Auth script that I
hope to get implemented in the near future, but this looks like a step
in the right direction.

Thomas 

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