Re: [RFC][NSE] Incomplete HTTP response body

Daniel Miller <[email protected]>
Newsgroups gmane.comp.security.nmap.devel
Message-ID <CABmvJnO8XE1GuxxwZ7+P+TGXM5OQd7asu8nvvTr5xa2xrc91Rg@mail.gmail.com>
nnposter,

On further review, this patch looks good. I would be happy with it as-is,
but here are my comments on your questions:

it would be trivial to store the
> fragment in the "body" member.
>

I don't think this is necessary, and would require more extensive checking
of existing scripts to make sure they aren't relying on some aspect of the
"error" body=nil condition.


> * The body fragment does process chunked encoding. It concatenates all
> processed chunks up to the point of failure.
>

This makes sense, I don't see a reason for it to be the other way. If a
script cares about chunks as separate entities, then it probably doesn't
want the higher-level http.lua library anyway.


>
> * The patch does not try to preserve received headers or the status
> line, only the body itself. This functionality could be added. (If yes,
> then the follow-up topic would be how to store them in the response
> object. My proposal would be to repurpose "fragment" to contain an
> incomplete response object, i.e. the headers or the body would be in
> resp.fragment.header and resp.fragment.body, respectively.)
>

I don't think we need to do this now, but if you copy and paste this
suggestion into a comment at the place where the code would have to go, it
will leave a clue as to a smart way to go about it if someone finds the
need to do so in the future.

Dan

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.