Indicating the end of a header block

[mnot]

HTTP/2 currently allows for multiple sets of headers. However, it was asserted in Tokyo that data on the same stream could race the header blocks, so seeing a data frame on a stream is not necessarily an indication that the headers are complete.

[martinthomson]

Ordering is guaranteed, so I'm not sure what the race would be. We can guarantee that headers are sent before data.

I originally thought that this issue was required simply because our maximum frame size is now too small for headers to fit into a single frame. @grmocg noted that his solution for #2 would require a continuation bit, which could fit the bill here.

That doesn't account for the fact that multiple blocks of headers could be sent at any time. We probably need to agree on what the semantics of that would be and what constraints we want to apply. The draft says something about having multiple header blocks for push, which seems necessary. It doesn't say anything about what HEADERS frames mean during or after the data frames are sent.

[mnot]

Yes, the race confused me too. @grmocg - any further thoughts?

The most straightforward thing to say would be that all header blocks before the first data block on a stream have the same semantics as the HTTP/1 header block; anything afterwards is considered a trailer.

[grmocg]

There are some issues when deploying over SCTP, but we're not doing that, so I'd be confused about that.
I do know, however, that there are servers where some portion of the data is available before all of the data that would be necessary for the headers has been computed.

As an example, imagine that you're serving a javascript resource which varies depending on some of the parameters of the query, and you must do a lookup on some other server to determine what they mean, however you know that some of the data is always the same, and thus would like to emit it blindly, before computing content-length, etc.

I think the usecase is probably weak.

[mnot]

Sure, this is a problem in HTTP/1 too; right now, you have to buffer the body before you emit headers. I wouldn't characterise it as a weak use case, it's fairly common IME.

I think we have two possible paths here -

1. We can make the end of headers implicit (probably indicated by the first data block)
2. We can make it explicit (e.g., with a flag; whether that's the absence of the continuation flag, or something else TBD)

An explicit indication will enable the use case you mention, as well as make it possible to late-bind the status (e.g., if an error is encountered while generating the body). However, it would require that 2->1 gateways buffer the entire response to make sure they see all of the headers; that's likely to be a showstopper.

Anyway, we should take this discussion to the list.

[martinthomson]

Perhaps the easiest thing to do is to make it very clear that headers finish before data starts. Then, we can debate the merits/problems of late headers.

[mnot]

See also #98

[grmocg]

I think the traditional solution (which Martin was advocating) as used in HTTP/1 is still reasonable. Send the headers first, then send the data. If that requires queuing, too bad.
If we find that we want/need trailers or some other kind of headers to deal with this kind of thing later, then we can deal with it then.

The best solution is then, probably:
Endpoints MUST send HEADERS before DATA on any stream (this jives with recent discussion about having only HEADERS open up streams).
Proxies MUST NOT reorder HEADERS and DATA on a single stream when forwarding.

[mnot]

Discussed at SF Interim.

Considering dropping Trailers as a features in HTTP/2.0; will ascertain support on mailing list.

If we decide to keep them, a fin flag on a header block that isn't the first is the start of trailers; any interspersed header frames have no semantics in HTTP/1.1.

[jasnell]

Trailers are addressed in the layering branch rewrite of the http layer.

[jasnell]

Ordering requirements for headers and data are addressed in layering branch as well