Nmap Development mailing list archives
Re: bugs in http.lua?
From: Patrik Karlsson <patrik () cqure net>
Date: Mon, 30 Nov 2009 09:53:01 +0100
Hi Joao I'm submitting a new patch that correctly handles the HTTP 100 Continue block of headers. My first patch incorrectly assumed that it was directly followed by a block of HTTP 200. The patch currently solves the issues I was having. //Patrik
Attachment:
http.lua.patch
Description:
On 30 nov 2009, at 09.21, Joao Correa wrote:
On Mon, Nov 30, 2009 at 1:14 AM, Ron <ron () skullsecurity net> wrote:Joao had revised a good part of http.lua for handling multi-part requests better. I'm not really sure if he ever completed it or if it got integrated. Joao, do you remember?Hi guys, I've been really busy these days, and that's why I'm not contributing very much. As far as I remember, I've finished all those handlings, but it is possible that something have been left behind. I'm aware about a bug on header handling (pointed to me by David) and about a lot of improvements that can be done to the pipeline. I also plan to fix them asap. If Patrik does not find a way of fixing the problem, I'll add this task to my schedule.Patrik Karlsson wrote:I'm currently re-writinig my Citrix xml plugins to use the http module, but have come a cross some problems. The first problem is that the content I'm sending to the server is of text/xml rather than application/x-www-form-urlencoded. I manage to change this by calling http.post with the following table in the option parameter: { header={["Content-Type"]="text/xml"}} This solves one problem, but the buildPost function then replaces all spaces with pluses, which is probably right for application/x-www-form-urlencoded but in my case it breaks my xml post. I've managed to work around this in my code by calling http.request and http.parseResult directly instead. The downside is that I have to build the http headers myself. The next problem is that the server responds with a "HTTP/1.1 100 Continue". So basically what the http module gets is this: HTTP/1.1 100 Continue Server: Citrix Web PN Server Date: Sun, 29 Nov 2009 22:03:42 GMT HTTP/1.1 200 OK Server: Citrix Web PN Server Date: Sun, 29 Nov 2009 22:03:42 GMT Content-type: text/xml Transfer-Encoding: chunked Transfer-Coding: chunked DATA GOES HERE .... As the module splits the headers from the body by searching for "\r?\n\r?\n" it incorrectly ends up with the second block of HTTP headers as data. By calling http.request directly I have the possibility to cut away this excessive block of headers myself before sending the data along to the parseResult function. I'm attaching a patch that fixes both the space to plus conversion issue and the additional http header issue. If I'm missing something completely obvious or using the http module incorrectly please let me know. //Patrik ------------------------------------------------------------------------ -- Patrik Karlsson http://www.cqure.net ------------------------------------------------------------------------ _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/-- Ron Bowes http://www.skullsecurity.org/
-- Patrik Karlsson http://www.cqure.net
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- bugs in http.lua? Patrik Karlsson (Nov 29)
- Re: bugs in http.lua? Ron (Nov 29)
- Re: bugs in http.lua? Joao Correa (Nov 30)
- Re: bugs in http.lua? Patrik Karlsson (Nov 30)
- Re: bugs in http.lua? Joao Correa (Nov 30)
- Re: bugs in http.lua? David Fifield (Dec 12)
- Re: bugs in http.lua? David Fifield (Dec 12)
- Re: bugs in http.lua? Ron (Nov 29)