- 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>
------ 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 UTC