Hi Vijay,
I think we know the issue of the extra numbers before and after the json
return: the server used chunked encoding:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: application/alto-endpointprop+json
Date: Tue, 06 Nov 2012 04:33:56 GMT
82
{
"meta" : {},
"data" : {
"map-vtag" : "1352176329",
"map" : {
"ipv4:192.168.1.23" : {
"pid" : "mypid2"
}
}
}
}
0
A client supporting chunked encoding will remove those number and a client
(e.g., nc) does not will keep them. The examples in the current spec all
use content length. Do we want to say something here or not?
Richard
On Mon, Nov 5, 2012 at 7:42 PM, Vijay K. Gurbani <[email protected]> wrote:
> Folks: By my count, we have 4 servers and 2 clients that will be
> part of the ALTO interoperability.
>
> Assume that we have servers S1, S2, S3, S4 and clients C1 and C2, I
> propose that we divide our time in 1/2 hour slots to ensure that all
> of the pairings are tested within 2 hours (+/- 1/2 hour or so).
>
> Thus we have the following pairings:
>
> 8:15-8:45 8:45-9:15 9:15-9:45 9:45-10:15
> S1-C1 S3-C1 S1-C2 S3-C2
> S2-C2 S4-C2 S2-C1 S4-C1
>
> If anyone has an alternative idea to proceed, please let me and
> Enrico know.
>
> At the end of the interoperability tests, can each pair please report
> the following to the chairs:
>
> Total tests attempted:
> Total tests passed successfully:
>
> 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
