bugs in http.lua?

[Patrik Karlsson <patrik () cqure net>]

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

Attachment: http.lua.patch
Description:

--
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/