- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 07 Aug 2012 16:14:44 +0000
- To: Mark Nottingham <mnot@mnot.net>
- cc: James M Snell <jasnell@gmail.com>, Roberto Peon <grmocg@gmail.com>, ietf-http-wg@w3.org
In message <31B0E5DA-AB4C-4077-AF20-094A9A2D8E91@mnot.net>, Mark Nottingham wri tes: >> 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. Ok, if you want to be a strict OSI-ortodox-semantician, HTTP is the presentation layer protocol because it can transfer a MIME type. Most people outside the church of OSI see HTTP as the default transport protocol and use it for everything from real-time traffic over RPCs to scheduled batch-transfers. Not because, mind you, of any inherent quality of the protocol, but because it is easier to interface with than TCP, provides a higher level abstraction than a byte-stream, but mostly because it already passes through firewalls... And with that out of the way... I don't care if you call it transport, presentation or application level: Expect/Continue does not work and should not be allowed into HTTP/2.0. >> 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.
Received on Tuesday, 7 August 2012 16:15:11 UTC