Some general SPDY feedback / questions

Just need a few clarifications as I've been going through the spec... some
of these are probably obvious but I wanted to get the "official" answer...

1. Section 3.2 HTTP Request/Response is fairly under-defined.
   For example...
   - are all request headers REQUIRED to be contained within the SYN_STREAM
or can some be pushed off to additional HEADERS frames? Likewise with
SYN_REPLY frames.
   - is it possible to interleave HEADERS and DATA frames within a request
or response Stream? (I noticed discussion of this with regards to
server-push, but did not see any discussion of it with regards to regular
http methods)
   - Since SPDY effectively eliminates Transfer-Encodings, are Trailers
still allowed? That is, for example, what if I wanted to send a HEADERS
frame containing a Content-Integrity header following a set of DATA frames?

  (Personal Opinion: it should be possible to interleave HEADERS anywhere
into the stream. With a few specific exceptions, It should also be possible
to override a given headers value by sending another instance of the header
along later in the same stream. Doing so raises the possibility of more
efficient multipart encodings, incremental data-integrity checks, etc)

2. Just for the sake of clarity, what is the expected behavior if a
user-agent interleaves multiple modification requests to the same resource?
For instance:

   => SYN_STREAM(id=1,:method=PUT,:path=/my/resource)
   => SYN_STREAM(id=2,:method=DELETE,:path=/my/resource)
   => SYN_STREAM(id=3,:method=POST, :path=/my/resource)

   While this may appear on the surface to be a silly question, it speaks
to a fundamental issue of allowing unsafe/non-idempotent methods to be
multiplexed, particularly if the processing order for requests interleaved
on a single connection is indeterminate. From
draft-ietf-httpbis-p1-messaging-20 6.3.2.2:

     Clients SHOULD NOT pipeline requests using non-idempotent request
     methods or non-idempotent sequences of request methods (see Section
     2.1.2 of [Part2]).  Otherwise, a premature termination of the
     transport connection could lead to indeterminate results.  A client
     wishing to send a non-idempotent request SHOULD wait to send that
     request until it has received the response status line for the
     previous request.

3. How are Informational 1xx Status Codes handled? The current SPDY draft
does not appear to support "provisional responses".

4. Note that the Upgrade header as currently defined within HTTP/1.1 will
need to be revisited. In fact, as currently defined, Upgrade is
incompatible with SPDY.

5. There's a fairly obvious security DoS concern about allowing a user
agent to multiplex multiple ranged GETs over a single connection. See
draft-ietf-httpbis-p5-range-20 Section 7.1 on "Overlapping Ranges".

6. It's good that Section 5.4 deals with cache control validation with
server push but the requirement needs to be made stronger. If the
originating stream utilizes any content negotiation mechanisms at all, and
those mechanisms impact the selection of resources that are pushed to the
client, the *server* MUST include an appropriate Vary header with the
pushed content. Right now, the spec states only that "browsers MUST be
careful to inherit request headers" ... but that leaves out any possible
intermediary caches along the way, which can obviously cause major problems.

7. What methods can trigger a server push? For instance, if I send a POST
request, is it possible for the server to respond with a push? For example,
I send a POST to a server to modify an image. In response to the POST, the
server returns a 200 OK with a page describing the changes and pushes the
modified image resource in a separate stream. Or are pushes only triggered
by GET requests? What are the conditions in which a push would be
considered inappropriate?


- James