Complete Request Flow

Assuming that we have solutions for push promises, 100-continue, and
trailers.  I've drawn up a basic sequence diagram:

http://www.websequencediagrams.com/?lz=dGl0bGUgSFRUUC8yLjAgUmVxdWVzdCBhbmQgUHVzaAoKQ2xpZW50LT5TZXJ2ZXI6IEhFQURFUlMrUFJJT1JJVFkgKG5ldyBzdHJlYW0pIFsxXQpvcHQgMTAwIENvbnRpbnVlCiAgADcGLT4ARwYAPAkAKgVlbmQAVBFEQVRBIFswLi5uXQoAIBwASBBQVVNIX1BST01JU0UAgQoPAEcGbm90ZSByaWdodCBvZgCBEAc6IHB1c2hlcyBjAIEqByBvbiAAgUsKc1xuYXQgcwCBegUgZGlzY3JldGlvbgCBBxEAgSgMb3B0IHRyYWlsZXJzAIFdIg&s=napkin

Regarding push promise:
We probably don't care from a security perspective, but the fact that a
push promise effectively blocks an HTTP client from making a request for
the identified resource should be cause for some concern.  A client
implementation that relies on the server's promise probably needs some sort
of timeout function (and RST_STREAM accordingly) to avoid being locked out
from promised resources.  Note that push is only truly effective if the
time between promise and data transmission is less than 1 RTT.  Rather than
define another mechanism, it's probably sufficient to describe this failure
case.

Regarding 100-continue:
This seems relatively easy to add.  The usual considerations for Expect:
apply.

Regarding trailers:
I'll note that it would be possible to send additional headers at any time
prior to the closing of a stream, even during data transmission.  I think
that we should allow for that because implementations will be tempted to
send headers frames immediately, which could lead to the packet scheduler
pushing them ahead of final data packets.  That's relatively harmless, and
it might even allow for more efficient operation in some cases.