headers
Roberto Peon | 18 Jul 2012 23:35
Picon

Re: Some general SPDY feedback / questions



On Wed, Jul 18, 2012 at 1:35 PM, James M Snell <jasnell-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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:
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):
 

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

 

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

Permalink | Reply |

Gmane