W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re[4]: HTTP2 Expression of Interest : Squid

From: Adrien de Croy <adrien@qbik.com>
Date: Tue, 17 Jul 2012 10:41:13 +0000
To: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
Cc: "Amos Jeffries" <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <emc7be1028-2d4d-4336-b386-fbf9464e9559@reboist>



------ Original Message ------
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
>In message <em264a739a-df76-4365-be1c-3dd9649ec57a@reboist>, "Adrien de Croy" w
>rites:
>
>
>>
>>Real-time notifications is something I find quite interesting, and that
>>would only really work if requested by the client, but then at any
>>stage until the connection is closed or whatever, messages could be
>>sent.  May not be cachable, but that would make no sense anyway for a
>>notification.
>>
>
>
>But that you can already do, and many apps do: chunked encoding
>that just somehow fails to get to the end...
>

problem is you can't tell if an intermediary will rechunk or spool 
until it thinks it has an entire message.

So allowing multiple messages on the stream after a push request by the 
client would allow an intermediary to perform message processing in a 
more deterministic manner.


>
>
>But I think it is imperative that nothing gets sent unless asked
>for first, explicitl, by the client.
>

I agree, and actually I'd be keen to apply this philosphy in both 
directions, where no significant resource is transmitted in either 
direction without the recipient indicating prior willingness (either by 
requesting it, or indicating willingness).  What I'm getting at here is 
large POST / PUT requests.  Currently it's a mess esp with auth in the 
mix.

Adrien



>
>
>
>--
>Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>phk@FreeBSD.ORG         | TCP/IP since RFC 956
>FreeBSD committer       | BSD since 4.3-tahoe
>Never attribute to malice what can adequately be explained by incompetence.
>
>
Received on Tuesday, 17 July 2012 10:41:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 17 July 2012 10:41:55 GMT