Transfer-Encoding: chunked allows message bodies to be generated without knowing the size of the full contents of the message prior to sending it (for the Content-Length header). Also, because transfer-encoding is a protocol-level feature, it can be applied to messages by proxies, so even a sender which always sends non-chunked messages can't guarantee that a non-chunking server will get the request correctly. This bug applies only to decoding incoming messages whose bodies have been encoded this way (and thus depends on support for message bodies, from bug 366371). Sending chunked messages is important in obviating the current requirement of buffering the entire message before sending it (for example, if one wanted to test that downloads of files >4GB work correctly). Since this will require API additions to allow handlers to control when data past the request headers has been generated, it'll be another bug for the future which will require more thought to implement correctly.

> Sending chunked messages is important in obviating the current > requirement of buffering the entire message before sending it Well another possibility would be just not to send a content-length header. (but, I do agree that supporting chunked at least for sending would be nice).

Since bug 343872 seems to be only for chunked+gzip, if it's fixable its test will probably need this.

Moving httpd.js bugs to the new Testing :: httpd.js component; filter out this bugmail by searching for "ICanHasHttpd.jsComponent".

...and changing the QA contact as well. Filter on the string "BugzillaQAContactHandlingIsStupid".