Dear all, Or adding a single sentence about potential issues of clients which aren't rfc2616 compliant in Section 6.3 would benefit readers a lot.
Thanks. --Jason On Tue, Nov 6, 2012 at 12:46 PM, Y. Richard Yang <[email protected]> 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 > > > On Tue, Nov 6, 2012 at 11:53 AM, Richard Alimi <[email protected]> wrote: > >> >> On Tue, Nov 6, 2012 at 7:15 AM, Vijay K. Gurbani <[email protected]>wrote: >> >>> 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. >>> >>> >> FWIW, I believe in an earlier version of the draft we were more explicit >> and specified that clients must support chunked encoding. The guidance we >> received at that point was to not reiterate details from the rfc2616. >> >> Rich >> >> >>> >>> 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} / >>> vijay.gurbani@alcatel-lucent.**com<[email protected]> >>> Web: >>> http://ect.bell-labs.com/who/**vkg/<http://ect.bell-labs.com/who/vkg/> >>> >>> >>> ______________________________**_________________ >>> alto mailing list >>> [email protected] >>> https://www.ietf.org/mailman/**listinfo/alto<https://www.ietf.org/mailman/listinfo/alto> >>> >> >> > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
