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

Re: Some general SPDY feedback / questions

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
Message-ID: <64411.1344356084@critter.freebsd.dk>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 7 August 2012 16:15:25 GMT