Re: http-methods & http-trace NSE Script Enhancement Ideas

[Patrik Karlsson <patrik () cqure net>]

I see two options;
> 1. The script is adapted not to use the generic_request method anymore but
> rather use the method specific function such as get, put, head that already
> have redirect support. A mapping would have to be made in the script to
> know what function to use for what method and the missing method specific
> functions would need to be created (more or less copied from existing ones,
> eventually leaving out cache support).
> 2. The script continues to use generic_request and implements the redirect
> function either locally or by removing the local keyword infront of those
> functions in the http library so that their visible to the script.
>
> Personally, I think I would go with alternative 1.
>
> //Patrik
>
> --
> Patrik Karlsson
> http://www.cqure.net
> http://twitter.com/nevdull77
>
>
> Hi Patrik, I'm confused by your suggestion #1 it seems to suggest two
> different ideas.
>
> We can't use a method specific function to perform a request using a
> different method. (i.e.: you can't do HTTP TRACE via HTTP GET....).
> What mapping would be required in #1 if the method specific functions were
> added to the base library (i.e.: http.trace and http.options)?

Sorry, I thought the answer was pretty straight forward, reading it again I
realized maybe not :) No obviously we can't do TRACE with GET, that was
what I tried to get at with "and the missing method specific functions
would need to be created". For the mapping it could be a simple lua table:

local mtof = { ["TRACE"] = http.trace, ["GET"] = http.get }


> Maybe I'm missing something but wouldn't it make the most sense to extend
> the existing redirect functionality within the HTTP library to
> generic_request with the default set to false? Then handling of redirection
> would be possible on any HTTP method (current or future).

I guess you could do that, but if I remember previous discussions
correctly, we wanted to keep the generic_request as "raw" as possible and
have the caching and redirect code in the method specific functions.


> Note, I haven't looked into this at all but with regard to the current
> redirect functionality if the redirect does not meet one of the base
> libraries requirements then it might be nice to pass those details back to
> the calling function or script. i.e.: if the redirect isn't followed
> because it's off-domain or off-host (port, protocol, etc) it would be nice
> to the calling function or script to be able to report such (esp. in
> verbose mode....for example "Redirect not followed due to off-domain
> location.").

Yes, that would be a nice addition and it shouldn't be too hard to add.

//Patrik

-- 
Patrik Karlsson
http://www.cqure.net
http://twitter.com/nevdull77
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/