On 11/05/2012 10:29 PM, Y. Richard Yang wrote:
Hi Vijay,
I think we know the issue of the extra numbers before and after the
json return: the server used chunked encoding:
[...]
A client supporting chunked encoding will remove those number and a
client (e.g., nc) does not will keep them.
Richard: OK, that explains the numbers in nc output.
The examples in the current spec all use content length. Do we want
to say something here or not?
I am leaning to no primarily because rfc2616 makes it mandatory to
receive and decode the chunked transfer encoding. Since nc is not
rfc2616 compliant, but we require ALTO clients to be (section 6.3 of
the ALTO protocol), I think we do not need to specify anything more.
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
