Re: Some general SPDY feedback / questions

On 07/08/2012, at 11:14 AM, "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:

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

You characterised it as "transport" flow control, which is already part of the SPDY proposal. I'm pointing out that they are not the same thing, at all.


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

I know it causes problems for intermediaries. We can talk about that, but just arguing by assertion doesn't help.


> 
>>> 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:18:51 UTC