Re: [NSE patch] patch for http.lua to support chunked encoding

[Sven Klemm <sven () c3d2 de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Kris,
|
|> The patch also changes the way the body of the document is
|> concatenated. Currently the http library uses "\r?\n" as line
|> separator and "\n" when concatenating. The patch changes this to use
|> "\r\n" in both cases so the document is no longer modified by the http
|> library.
|
|
| I started writing this email objecting to this change because at
first it
| didn't seem like it would work correctly (because of your
explanation).  But
| as I continued to write and actually re-examined the implementation
of the
| library and your patch, I realized it should work, but not the way I
inferred
| from your email.  I haven't tested your changes, though, and this is
not about
| your chunked encoding support at all.
|
| What I got from your email was that the library was doing a roundabout
| possible conversion of \r\n to \n between reading and concatenating,
and it
| sounded like the purpose of the patch was to eliminate these
differences so
| that it will always be \r\n and no conversion is taken place.  This
is where I
| was initially objecting because the first thing to enter my mind was
the fact
| that the HTTP header EOL (\r\n) and the body EOL could be different
(like \n).
|
| However, I think this will work because the simple \r\n separator
will work
| for the HTTP header just fine, but it will not cycle through the
lines of the
| body if it has an EOL of \n or something else.  But this is not a
problem the
| way the library is currently implemented (just copying the body)
because the
| buffer() returned from make_buffer() should still return the final
data (the
| body) if it's not separated by \r\n.  So the body will get returned
in one
| unmodified chunk, which is just fine for what we want.  And even if
the body
| EOL is \r\n, it should still work fine.
|
| Soooo... I suppose the purpose of this rewritten email is say
that--while I
| don't know which one of us was confused--I think this change is OK (and
| probably even slightly better performance-wise) even though I got
something
| totally different from your initial email.  Hopefully it is anyway
because
| I'll look even funnier having written all this about changing my
mind about
| this simple change and then turning out to be wrong in the end :)

I was aware that the body EOL could be different from the header one
or that the body might not even contain an EOL but as you already
stated it does not matter because of the way the library works.
So your final analysis is right :)

The reason I combined this change with the chunked encoding patch is
that the '\r?\n' makes counting the bytes in the chunk hard as I don't
know whether there was a \r or not.
But removing the EOL conversion is a change that makes sense in
itself. The http library should not modify the data.

Cheers,
Sven


- --
Sven Klemm
http://cthulhu.c3d2.de/~sven/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkix5uQACgkQevlgTHEIT4ZCGgCfbaEgkIeNETyDiaqykkouvShH
lycAn28ZUWHHFssoedlntlZrCU+a43Jh
=Ri7o
-----END PGP SIGNATURE-----

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