Re: Some general SPDY feedback / questions

On Wed, Jul 18, 2012 at 1:35 PM, James M Snell <jasnell@gmail.com> wrote:

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

It depends.
For server push, split headers (i.e. some in SYN_REPLY, some in a HEADERS
frame) are expected.
For normal requests, this isn't the case.

One of the solutions that was discussed was to have a flag in any of the
header blocks on these frames which indicated that we'd entered a different
phase of metadata processing, e.g. once for the request or reply, then
another for trailers/chunk extension equivalent.

Here is the most recent discussion on the matter:
  https://groups.google.com/d/topic/spdy-dev/KO8rMMFGzd8/discussion
The changes mentioned here didn't get folded into the spec, but probably
should have.
The spec could and should be much clearer on this, and the protocol should
be changed to make it very obvious. :/


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

It is.


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

We keep going round and round on that. It isn't well spec'd because no-one
who implements spdy client-side has yet had an implementation that would
use them.
Theoretically, you'd just use a header frame at the end.


>
>   (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:
>

The spec doesn't define the behavior, as you've noted. The expectation is
that HTTP semantics w.r.t. non-idempotent methods will be preserved for
HTTP streams.
This is not optimal in a number of ways. Personally, I'd love to leave it
up to the application and provide more rich signaling as to when requests
were sent, response headers received, etc.


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

Here is the most recent discussion on the matter (same one as before):
   https://groups.google.com/d/topic/spdy-dev/_DJSgQ-3PP0/discussion


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

Sure, are you up for changing it to how you'd like it to read?
The most current version of the spec is hosted on Github here (and we make
changes to it there):

   https://github.com/mbelshe/SPDY-Specification/tree/gh-pages


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

Any request could trigger a push. The server cannot do a push until there
is a request, and all pushed resources are associated with one request,
though the responses could be used by multiple pages/page views.
-=R


>
>
> - James
>