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

[Kris Katterjohn <katterjohn () gmail com>]

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

Sven Klemm wrote:
> Hi,

Hey Sven,

> 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 :)

> Cheers,
> Sven

Thanks,
Kris Katterjohn


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

iQIVAwUBSLHMJv9K37xXYl36AQLYMA//TSmZgynQ4TmLAb9hQoFlpO1Qbza1D00S
xHzlnjdukYNT8e63hZ+4BlNNxmJebc5GEMI+nVxESDVe58OJfnXYLRoDr4OjHcng
i561wDjHXwBwSiROtt9WlSoBuXASpIswMRH/ANjmodyLhirJ0s5dIQAzkRZleL9h
epTpexIxd+IRaJZyk10MK/89rxTbF3yxIH+KFmL7seBLxhRbgj1zBV8GFOb8N81w
JdZdpukNrP3bKHdTxw+sPhwv+sIihB9brlDs3QhcE/47BJuQknF2zqRBno2RfRV8
uisbD3T2absR1l2gnA69KYPB3T+HxLDzpYnd5A/x+aEjPJqizgvhDW8a4Rr7xuHZ
rf/r7qtBohn91huAZttnTKpvhwBqgwgKzjF/IVHSaWDkJlDmepeUcg9C1s3P+C35
L473zlFsiU5c4Y/HlYc0HAay/jnkyS3hzNKyfgNZ/Zz+WTq7CzT+2kZMxWXq8gnT
1ZRdCEtvNGh8XnwA21Xv5Ia1+tYzY933ITfHPJCrZ9vhUhqeedCEJLcqmORqP3oh
lnmLDNt9jYvgi+d16LGrNPiMaZC/rou50oFNoB8zI/ywjBrvr/w2XPbFn/TYp0Mx
ZaxJlSDggviQrgo+gWsxdTRN25I9ZPiLYVsf1ZJsKdso1tOiVgMJSM4iEsSRsTyG
p/ZZSSdjnWw=
=Li/q
-----END PGP SIGNATURE-----

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