On 11/06/2012 11:46 AM, Y. Richard Yang wrote:
Hi Rich, Vijay,
No action makes sense to me. From this experience, I may suggest that we
add a suggestive sentence about
potential issues of not handling chunked encoding, just for the benefit
of readers. What do you know?
Richard: I am rather conflicted on what to do. Clearly, nc is not a
RFC2616 client, and just as clearly, any RFC2616 client will support
chunked encoding.
I also realize that we spent some time at the bakeoff looking at the
byte count prefix in nc(1) but not correlating it immediately with the
"Transfer-Encoding: chunked" header, so saying something seems
appropriate.
In the end, I think I will chalk this upto us being tired and cranky
late at night.
But, if the editor team of the protocol document can find a place to
exhort implementations to pay attention to transfer encodings applied
to message bodies without reiterating rfc2616, then please proceed. I
tried to spend some time thinking how to do this, but could not arrive
at a reasonable set of words. So alas, I cannot contribute any text
to get you started ...
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email protected]
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
