- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 7 Aug 2012 11:00:33 -0500
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: James M Snell <jasnell@gmail.com>, Roberto Peon <grmocg@gmail.com>, ietf-http-wg@w3.org
On 07/08/2012, at 10:58 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > In message <E67EC141-85D9-4F64-920F-9F3EAB251DC7@mnot.net>, Mark Nottingham wri > tes: > >> I'd characterise expect/continue as being on the lighter borders of a >> grey area; it is used, but it does cause interop problems. >> [...] >> I'd be interested to hear comments from others, of course. > > Expect/continue should not be allowed in HTTP/2.0, it is a transport > flow-control mechanism and it does not work. No, it's an application flow control mechanism, not transport. I.e., your transport layer (TCP) doesn't do anything with it; neither does the transfer layer (HTTP). It's used by the application itself to determine if a request should be sent -- the semantics are surfaced, visible and used by it. > > My strawman for how to do it in HTTP/2.0: > > The client can have no more than one TCP connection with six > outstanding requests, each with no more than 8KB of headers+body > in total, until the server sends an explicit message increasing its > allowance, either in stand-alone message if we have a control > channel, or as part of a response. > > All numbers are examples subject to improvement. > > -- > 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. -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 7 August 2012 16:01:01 UTC