Nmap Development mailing list archives
Re: [NSE patch] patch for http.lua to support chunked encoding
From: Kris Katterjohn <katterjohn () gmail com>
Date: Sun, 24 Aug 2008 16:01:29 -0500
-----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
Current thread:
- [NSE patch] patch for http.lua to support chunked encoding Sven Klemm (Aug 23)
- Re: [NSE patch] patch for http.lua to support chunked encoding Kris Katterjohn (Aug 24)
- Re: [NSE patch] patch for http.lua to support chunked encoding Sven Klemm (Aug 24)
- Re: [NSE patch] patch for http.lua to support chunked encoding Fyodor (Aug 29)
- Re: [NSE patch] patch for http.lua to support chunked encoding Kris Katterjohn (Aug 24)