Subject: Re: Some general SPDY feedback / questions

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Aug 2012 10:43:58 -0500

On 19/07/2012, at 1:37 AM, James M Snell <[email-masked]> wrote:

> 
> On Jul 18, 2012 2:35 PM, "Roberto Peon" <[email-masked]> wrote:
> >[snip]
> >> 3. How are Informational 1xx Status Codes handled? The current SPDY draft does not appear to support "provisional responses". 
> >
> >
> 
> Thank you for the reference to the thread. After reading through it one thing became obvious: while it would likely not be difficult to provide support for a 100-continue like mechanism within spdy, the protocols current design would essentially require a suboptimal hack in order to retain existing http/1.1 semantics and preserve spdy-to-http1.1 pass through or would require that we design a new similar mechanism, optimized for spdy that changes an aspect of http/1.1 semantics.
> 
> As Mark  has pointed out recently, however, our job here currently is to only define a new transport for http and not to change existing http semantics. So i am at a bit of a loss as to what the charter will let us do in this case.
> 
> Mark... any guidance?

It's a good question. I know that it has come up often on the SPDY list (sometimes raised by me ;).

I'd characterise expect/continue as being on the lighter borders of a grey area; it is used, but it does cause interop problems.  HTTPbis hasn't decided to deprecate it, so it does form part of the semantics of HTTP (unlike, for example, chunk extensions, which we have deprecated).

However, that doesn't preclude us from deciding to not support it in HTTP/2, *if* we can get a good consensus around doing so. I'd be inclined to have a somewhat higher bar for doing so, however.

I'd be interested to hear comments from others, of course.

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 07 Aug 2012 15:58:34 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>I'd characterise expect/continue as being on the lighter borders of a 
>grey area; it is used, but it does cause interop problems.  
>[...]

Expect/continue should not be allowed in HTTP/2.0, it is a transport
flow-control mechanism and it does not work.

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
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Aug 2012 11:00:33 -0500

> flow-control mechanism and it does not work.

No, it's an application flow control mechanism, not transport. I.e., your transport layer (TCP) doesn't do anything with it; neither does the transfer layer (HTTP). It's used by the application itself to determine if a request should be sent -- the semantics are surfaced, visible and used by it.

--
Mark Nottingham
http://www.mnot.net/

---

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Tue, 7 Aug 2012 16:05:08 +0000

A mechanism like the 100-continue is critical for supporting requests containing entity data that results in authentication needed, redirect, or other "intermediate "responses in an efficient and robust manner. It allows the client to send the headers which the server can then use to determine whether it can accept the data and as a result give a go-ahead to the client. You don't want the client to start sending a lot of body data if it has to redo the request.

You can approximate this behavior with careful use of flow-control credits but it will inherently be much cruder because there is no way to separate cleanly on a header/body boundary. As a result it will likely result in wasted bytes transmitted -- something we want to avoid with HTTP/2.0.

Expect on the other hand is in general a failed experiment in my opinion -- you can't retrofit such semantics into an existing protocol.

Henrik

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Tuesday, August 07, 2012 08:44
To: James M Snell
Cc: Roberto Peon; [email-masked]
Subject: Re: Some general SPDY feedback / questions

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 7 Aug 2012 18:14:34 +0200

Hi Poul-Henning,

> flow-control mechanism and it does not work.

No, it's not a transport flow-control mechanism, it goes further by letting
the client send non-idempotent requests over established connections with
the ability to reply them in case of breakage. By sending even a few bytes
of data, you risk sending the whole request at once and being left in doubt
when the connection breaks. It is important to be able not to send the whole
request at once (at least stop before the last chunk).

Right now the way it works is awkwards and could be improved or reworked,
but there is a valid use of this mechanism even if it's sometimes quite
painful.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 07 Aug 2012 16:14:44 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Aug 2012 11:18:27 -0500

On 07/08/2012, at 11:14 AM, "Poul-Henning Kamp" <[email-masked]> wrote:

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

> level:  Expect/Continue does not work and should not be allowed

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

--
Mark Nottingham
http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Tue, 7 Aug 2012 09:29:30 -0700

> 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

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Tue, 07 Aug 2012 22:07:58 +0000

------ Original Message ------
From: "Henrik Frystyk Nielsen" <[email-masked]>
>A mechanism like the 100-continue is critical for supporting requests containing entity data that results in authentication needed, redirect, or other "intermediate "responses in an efficient and ro…
we had a discussion about this a couple years back, and it was resolved 
that the only way that 100-continue can provide for the ability to 
retain the client connection is if the client sends chunked request 
bodies, and aborts the transfer of the entity by sending a 0 chunk.

I'm not aware of any client that actually does this.

so AFAICT, 100 continue is unnecessary, and in the end just results in 
extra transmissions for pretty much no visible benefit.

If OTOH it allowed the client to decide not to send the body (e.g. to 
auth instead), it could have been useful.

This came up when I did my original proposal for status updates, in 
relation to multi-legged authentication when dealing with large request 
bodies.

Adrien

---

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Tue, 7 Aug 2012 22:20:43 +0000

This is not correct. Using the 100 continue model explicitly calls out separating on the header/body boundary. There is absolutely no reason for the client to use chunking. The use of 100 was introduced explicitly to deal with PUT and POST in situation where there is potentially a large RTT and it is exposed in common Web client APIs (one case is the .NET HTTP client APIS).

Henrik

-----Original Message-----
From: Adrien W. de Croy [mailto:[email-masked]] 
Sent: Tuesday, August 07, 2012 3:08 PM
To: Henrik Frystyk Nielsen; Mark Nottingham; James M Snell
Cc: Roberto Peon; [email-masked]
Subject: Re: Some general SPDY feedback / questions

------ Original Message ------

Adrien

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Tue, 07 Aug 2012 22:42:36 +0000

ok, now I'm confused.

you and I discussed this in Feb 2007 on this list 
(http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/ thread 
RE: [Fwd: I-D ACTION:draft-decroy-http-progress-00.txt])

My understanding is that once a request indicates an entity body, 
either it must be sent, or the connection closed.

If the desire is to keep the connection open (e.g. for NTLM), then the 
only option is either send the entire entity, or send it chunked from 
the beginning, and send a 0 chunk (which is actually as far as the 
receiver is concerned the same as sending the entire body) so the 
client can get on with authenticating.

100 Continue simply advises the client that it's possible (more 
likely?) the entity will be accepted, e.g. it's not a 401 or 407 or 3xx 
etc etc.

I can still envisage a server sending 100 continue then a 403 or 401 
after it scanned the content or something, or if some messaging layer 
sent the 100 and a higher one decided auth was required for that 
request.  I don't know if this is prohibited by the spec.

Adrien

------ Original Message ------
From: "Henrik Frystyk Nielsen" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>;"Mark Nottingham" 
<[email-masked]>;"James M Snell" <[email-masked]>
Cc: "Roberto Peon" <[email-masked]>;"[email-masked]" 
<[email-masked]>
Sent: 8/08/2012 10:20:43 a.m.
Subject: RE: Some general SPDY feedback / questions

---

From: Mike Belshe <[email-masked]>
Date: Tue, 7 Aug 2012 16:08:48 -0700

On Tue, Aug 7, 2012 at 8:43 AM, Mark Nottingham <[email-masked]> wrote:

> > >> 3. How are Informational 1xx Status Codes handled? The current SPDY
> draft does not appear to support "provisional responses".
> > >
> > >
> >
> > Thank you for the reference to the thread. After reading through it one
> thing became obvious: while it would likely not be difficult to provide
> support for a 100-continue like mechanism within spdy, the protocols
> current design would essentially require a suboptimal hack in order to
> retain existing http/1.1 semantics and preserve spdy-to-http1.1 pass
> through or would require that we design a new similar mechanism, optimized
> for spdy that changes an aspect of http/1.1 semantics.
> >
> > As Mark  has pointed out recently, however, our job here currently is to
> only define a new transport for http and not to change existing http
> semantics. So i am at a bit of a loss as to what the charter will let us do
> in this case.
> >
> > Mark... any guidance?
>
> I'd characterise expect/continue as being on the lighter borders of a grey
> area; it is used, but it does cause interop problems.  HTTPbis hasn't
> decided to deprecate it, so it does form part of the semantics of HTTP
> (unlike, for example, chunk extensions, which we have deprecated).
>
> However, that doesn't preclude us from deciding to not support it in
> HTTP/2, *if* we can get a good consensus around doing so. I'd be inclined
> to have a somewhat higher bar for doing so, however.
>

I agree with Henrik about 100 Continues - HTTP/2.0 must support them.  (I
don't like 100's much, but that is a different issue :-)

The reason I think we need to support is because its a battle we don't need
to fight.  It was in HTTP/1.1, and a few people use it, so prohibiting it
creates a barrier to adoption for HTTP/2.0 which has no impact on
performance or the other parts of HTTP/2.

Making SPDY (or HTTP/2.) suport it, however, is relatively simple.  James'
proposal in this thread is getting close.  I'm a little worried about
demarcation of the two sets of headers, but the rest is straightforward.

Mike

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 08 Aug 2012 11:17:51 +1200

On 08.08.2012 03:43, Mark Nottingham wrote:
> On 19/07/2012, at 1:37 AM, James M Snell wrote:
>
>>
>> On Jul 18, 2012 2:35 PM, "Roberto Peon" wrote:
>> >[snip]
>> >> 3. How are Informational 1xx Status Codes handled? The current 
>> SPDY draft does not appear to support "provisional responses".
>> >
>> >
>>
>> Thank you for the reference to the thread. After reading through it 
>> one thing became obvious: while it would likely not be difficult to 
>> provide support for a 100-continue like mechanism within spdy, the 
>> protocols current design would essentially require a suboptimal hack 
>> in order to retain existing http/1.1 semantics and preserve 
>> spdy-to-http1.1 pass through or would require that we design a new 
>> similar mechanism, optimized for spdy that changes an aspect of 
>> http/1.1 semantics.
>>
>> As Mark  has pointed out recently, however, our job here currently 
>> is to only define a new transport for http and not to change existing 
>> http semantics. So i am at a bit of a loss as to what the charter will 
>> let us do in this case.
>>
>> Mark... any guidance?
>
> grey area; it is used, but it does cause interop problems.  HTTPbis
> hasn't decided to deprecate it, so it does form part of the semantics
> of HTTP (unlike, for example, chunk extensions, which we have
> deprecated).

The interop problems seem to center around the timeout continuance 
required for 1.0 hops. If the semantics were able to be changed to drop 
connection instead of timeout Expect would have a much better behaviour 
profile.

> HTTP/2, *if* we can get a good consensus around doing so. I'd be
> inclined to have a somewhat higher bar for doing so, however.

I think its useful to keep for a narrow set of use-cases. Because 
Expect: provides the user/client with the power to mandate particular 
features. It will not be useful on the bulk of traffic as far as I can 
see, but for the paranoid it is actively useful.

IMO, the framing structures proposed for 2.0 is essentially mandatory 
chunking. So the chunked encoding detection use-case is not relevant 
over 2.0 hops. 1.1<->2.0 gateways can essentially be mandatory chunked 
support, and always respond 100-continue when it knows the rest of the 
path is 1.1 or higher (1.1 proxies can do that already today really).

Multi-legged auth on POST etc at a 2.0->1.1 gateway is still a 
bandwidth sucking point. 2.0 semantics for aborting a particular request 
should help optimize things there, particularly of the client end of the 
chain is all 2.0.

I vote for keeping Expect, and 100-continue semantics for secure 
client-driven negotiations. But deprecating the timeout possibility in 
favour of abort and making it clear that chunking negotiation is not 
relevant over 2.0 hops.

Amos

---

From: James M Snell <[email-masked]>
Date: Tue, 7 Aug 2012 16:19:43 -0700

What exactly is your worry?

My general concern about it deals more with application handling of the
response than with anything else... it would be good to apply some rules...
for instance...

1. An updated :status header MUST ONLY be sent if the initial SYN_REPLY
:status header is a 1xx response code,
2. No more than one 1xx response code can be sent per response,
3. Once a non 1xx :status has been sent, it is a protocol error to send any
additional :status headers,
4. The non 1xx :status header MUST be sent before any DATA frames are sent
in the response.

With that, an application can be assured that they'll have the final actual
status code before processing any of the response data.

- James

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Tue, 07 Aug 2012 23:26:51 +0000

------ Original Message ------
From: "James M Snell" <[email-masked]>
>My general concern about it deals more with application handling of 
>the response than with anything else... it would be good to apply some 
>rules... for instance...
>1. An updated :status header MUST ONLY be sent if the initial 
>SYN_REPLY :status header is a 1xx response code,
this contravenes 2616 which explicitly states that any number may be 
sent, and must be handled appropriately.

>3. Once a non 1xx :status has been sent, it is a protocol error to 
>send any additional :status headers,
this is a semantic change.   We actually now use multiple 1xx for 
status updates in the lab.  I don't know if there are other uses, but 
there are legitimate use-cases for it.

If 2.0 can support some other OOB notification mechanism, then all well 
and good.

Adrien
>4. The non 1xx :status header MUST be sent before any DATA frames are 
>sent in the response.
>
>With that, an application can be assured that they'll have the final 
>actual status code before processing any of the response data.
>
>- James
>
>
> Making SPDY (or HTTP/2.) suport it, however, is relatively simple.  
> James' proposal in this thread is getting close.  I'm a little 
> worried about demarcation of the two sets of headers, but the rest is 
> straightforward.
> 
> Mike
> 
>

---

From: James M Snell <[email-masked]>
Date: Tue, 7 Aug 2012 17:33:05 -0700

On Tue, Aug 7, 2012 at 4:26 PM, Adrien W. de Croy <[email-masked]> wrote:

> this contravenes 2616 which explicitly states that any number may be sent,
> and must be handled appropriately.
>
>
>   3. Once a non 1xx :status has been sent, it is a protocol error to send
> any additional :status headers,
>
> this is a semantic change.   We actually now use multiple 1xx for status
> updates in the lab.  I don't know if there are other uses, but there are
> legitimate use-cases for it.
>

Aw man.. you had to go and ruin it with Reality... how annoying ;-) I
suppose that, at least in theory, we could support multiple 1xx :status
headers to be sent so long as the final non-1xx :status is still sent
*before* any response DATA frames, but that does get kind of messy and
tedious... we'd end up having to check every HEADERS frame for a possible
:status header that overrides the previously received one... and that just
gets silly.

The one thing I would note, however, is that HEADERS frames can be sent
anytime in the stream making it possible for other kinds of signaling
beyond :status to occur. The only restriction being how such additional
HEADERS frames affect the HTTP semantics.

- James

> On Tue, Aug 7, 2012 at 4:08 PM, Mike Belshe < <[email-masked]>
> [email-masked]> wrote:
>
>>
>> [snip]
>>  James' proposal in this thread is getting close.  I'm a little worried
>> about demarcation of the two sets of headers, but the rest is
>> straightforward.
>>
>> Mike
>>
>>
>>
>>
>>>
>>> Cheers,
>>>
>>> --
>>> Mark Nottingham
>>> <http://www.mnot.net/>http://www.mnot.net/
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 08 Aug 2012 01:00:46 +0000

------ Original Message ------
From: "James M Snell" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Mike Belshe" <[email-masked]>;"Mark Nottingham" 
<[email-masked]>;"Roberto Peon" <[email-masked]>;"[email-masked]" 
<[email-masked]>
Sent: 8/08/2012 12:33:05 p.m.
Subject: Re: Some general SPDY feedback / questions
> >the response than with anything else... it would be good to apply 
> >some rules... for instance...

>>If 2.0 can support some other OOB notification mechanism, then all 
>>well and good.

>
>Aw man.. you had to go and ruin it with Reality... how annoying ;-) 
yeah sorry :)

It's not deployed, but it works great.  We patched Chromium for it, 
user experience on AV scanning at gateway is a zillion times better 
than what we had before.

anyway.

>I suppose that, at least in theory, we could support multiple 1xx 
>:status headers to be sent so long as the final non-1xx :status is 
>still sent *before* any response DATA frames, but that does get kind 
>of messy and tedious... we'd end up having to check every HEADERS 
>frame for a possible :status header that overrides the previously 
>received one... and that just gets silly.
how would you currently distinguish the 0 vs 1 vs N 1xx response 
anyway?   I think you'll need to look anyway.
>
>The one thing I would note, however, is that HEADERS frames can be 
>sent anytime in the stream making it possible for other kinds of 
>signaling beyond :status to occur. The only restriction being how such 
>additional HEADERS frames affect the HTTP semantics. 
yeah, late headers.  They give me a really bad feeling.

It gets really nasty any time anyone wants to enforce any sort of 
policy based on header content.  Can late duplicates override previous 
values etc etc.

I know that 1.1 has trailers with chunking (although I thought these 
were being deprecated).

There has to be some sane limit as to what sort of headers you can send 
any time.  For example sending Content-Type any place other than before 
the start of data is a train-wreck waiting to happen.

Intermediaries commonly pass payload via filter chains based on content 
type in order to avoid spooling.  If you had to wait until the transfer 
was complete before filtering, there would be quite an impact on 
perceived performance at the client.

Personally I'd avoid late headers like the plague, or severely restrict 
their use to only certain headers (I can't think of any I'd allow).

Adrien

> Adrien
> >4. The non 1xx :status header MUST be sent before any DATA frames 
> >are sent in the response.
> >
> > worried about demarcation of the two sets of headers, but the rest 
> > is straightforward.
> > 
> > Mike
> > 
> >

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 08 Aug 2012 18:12:02 +1200

On 8/08/2012 12:33 p.m., James M Snell wrote:
> On Tue, Aug 7, 2012 at 4:26 PM, Adrien W. de Croy <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     From: "James M Snell" <[email-masked] <mailto:[email-masked]>>
>>     My general concern about it deals more with application handling
>>     of the response than with anything else... it would be good to
>>     apply some rules... for instance...
>>
>     this contravenes 2616 which explicitly states that any number may
>     be sent, and must be handled appropriately.
>>     3. Once a non 1xx :status has been sent, it is a protocol error
>>     to send any additional :status headers,
>     status updates in the lab.  I don't know if there are other uses,
>     but there are legitimate use-cases for it.
> suppose that, at least in theory, we could support multiple 1xx 

Take a gander through the network-friendly-00 draft. Notice how the 
response status has a frame type of its own for precisely this use-case. 
The frame type and status value is easily available in the envelope 
octets for this validity check to be done at high speed without having 
to muddle through any of the rest of the frame(s) structure.

> additional HEADERS frames affect the HTTP semantics.

+1.

Amos

---

From: Mike Belshe <[email-masked]>
Date: Thu, 9 Aug 2012 14:22:50 -0700

On Tue, Aug 7, 2012 at 11:12 PM, Amos Jeffries <[email-masked]> wrote:

>> On Tue, Aug 7, 2012 at 4:26 PM, Adrien W. de Croy <[email-masked]<mailto:
>> [email-masked]>> wrote:
>>
>>
> The frame type and status value is easily available in the envelope octets
> for this validity check to be done at high speed without having to muddle
> through any of the rest of the frame(s) structure.
>
>
>

When you do this, it opens up a new set of things to define:
   - what happens if a header is superseded later? can you send the same
header twice?
   - when can a receiver know when headers are 'done'?  If you sent one set
of cache-related headers, can you send further ones later?

I know these sound like edges, and even the spdy framer sort-of allows
header frames at any time... but at the app layer, it creates a lot of new
questions that http doesn't have today.  this is why in SPDY we just said
"although the framing layer can do it, for HTTP's purposes, you (mostly)
can't".

Mike

---

From: Karl Dubost <[email-masked]>
Date: Thu, 9 Aug 2012 14:46:25 -0700

Henrik,

Le 7 août 2012 à 09:05, Henrik Frystyk Nielsen a écrit :
> A mechanism like the 100-continue is critical for supporting requests containing entity data that results in authentication needed, redirect, or other "intermediate "responses in an efficient and robust manner.

That's the spec
On the browser side, in Opera we had issues with some Web sites such as Instapaper and easyjet. Opera was sending 

Opera sends 
Expect: 100-continue

The server replies with 
100 continue

and then drop the connections for no reasons after a 200 OK before reaching the end of the Content-Length.

I don't remember if Opera decided to remove the support for it as it was creating troubles. I could check.

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations, Opera Software

---

From: James M Snell <[email-masked]>
Date: Thu, 9 Aug 2012 15:54:37 -0700

On Aug 9, 2012 2:26 PM, "Mike Belshe" <[email-masked]> wrote:
[Snip]
header twice?

There is a definite trade off in complexity, that's for sure... but if we
need to support 1xx responses I don't see another way to do it without
increasing the complexity even further.

Headers would essentially be single value, if a subsequent headers frame
repeats a previously seen header, the value for that header is replaced. If
the application has already processed that header, the application needs to
figure out how to handle the situation.

>    - when can a receiver know when headers are 'done'?  If you sent one
set of cache-related headers, can you send further ones later?

The headers are done once the first data frame is sent or the FIN is
received.

For cache headers, it would be important to note that repeated headers
would replace the existing value, not add to the value, so subsequent cache
control headers would supersede any that came before.

Understood, and the reasoning is sound, but there really doesn't appear to
be another simpler way of supporting provisional responses. There is an
increased burden on the developer to handle repeated headers properly but I
doubt that burden is much more than what developers are already accustomed
to.

- James

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Fri, 10 Aug 2012 00:09:04 +0000

do we even envisage sending entity headers on 1xx responses?

I don't know if it's a good idea.

in which case, we'd only get entity headers on the final response 
before the data.

Adrien

------ Original Message ------
From: "James M Snell" <[email-masked]>
To: "Mike Belshe" <[email-masked]>
Cc: "Amos Jeffries" <[email-masked]>;"[email-masked]" 
<[email-masked]>
Sent: 10/08/2012 10:54:37 a.m.
Subject: Re: Some general SPDY feedback / questions
>>    - what happens if a header is superseded later? can you send the 
>same header twice?
>There is a definite trade off in complexity, that's for sure... but if 
>we need to support 1xx responses I don't see another way to do it 
>without increasing the complexity even further.
>Headers would essentially be single value, if a subsequent headers 
>frame repeats a previously seen header, the value for that header is 
>replaced. If the application has already processed that header, the 
>application needs to figure out how to handle the situation. 
>>    - when can a receiver know when headers are 'done'?  If you sent 
>one set of cache-related headers, can you send further ones later?
>would replace the existing value, not add to the value, so subsequent 
>cache control headers would supersede any that came before. 
>>   
>> I know these sound like edges, and even the spdy framer sort-of 
>allows header frames at any time... but at the app layer, it creates a 
>lot of new questions that http doesn't have today.  this is why in 
>SPDY we just said "although the framing layer can do it, for HTTP's 
>purposes, you (mostly) can't".
>>
>Understood, and the reasoning is sound, but there really doesn't 
>appear to be another simpler way of supporting provisional responses. 
>There is an increased burden on the developer to handle repeated 
>headers properly but I doubt that burden is much more than what 
>developers are already accustomed to. 
>- James
>> Mike
>>
>>
>>
>>
>>>
>>>
>>> Amos
>>>
>>

---

From: James M Snell <[email-masked]>
Date: Thu, 9 Aug 2012 18:45:28 -0700

They're currently not forbidden but would be fairly pointless, so we may be
safe.
On Aug 9, 2012 5:09 PM, "Adrien W. de Croy" <[email-masked]> wrote:

> in which case, we'd only get entity headers on the final response before
> the data.
>
> Adrien
>
>
>
> Cc: "Amos Jeffries" <[email-masked]>;"[email-masked]" <
> [email-masked]>