Re: Some general SPDY feedback / questions

On Tue, Aug 7, 2012 at 9:18 AM, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 07/08/2012, at 11:14 AM, "Poul-Henning Kamp" <phk@phk.freebsd.dk>
> wrote:
> [snip]
> > 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.
>
>
The general concept is sound, the existing design definitely leaves much to
be desired. Given the bidirectional multiplexing available within SPDY,
however, we should be able to design something better, tho. The challenge,
that I see, lies not in SPDY specifically, but in the way that HTTP 1.1
semantics are implemented on top... with the HTTP response status being
bound to the SYN_REPLY. If, for instance, we allow for multiple ":status"
headers to be sent back the possibility to implement this opens up
significantly.

For example, let's suppose that we allow the server to send a follow-on
:status code within HEADERS frames... then we could implement this as ...

  C              S
  |=============>|
  |1) SYN_STREAM |
  | :method:POST |
  | :expect:100  |
  |<=============|
  |2) SYN_REPLY  |
  | :status:100  |
  |=============>|
  |3) DATA       |
  |<=============|
  |4) HEADERS    |
  | :status:201  |
  |              |

Yes, this is a change to existing semantics but, I think it's a reasonable
one that can be mapped down to a 1.1 flow if necessary.

- James


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