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/