Re: Some general SPDY feedback / questions
2012-07-18 21:35:22 GMT
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 188.8.131.52:
Clients SHOULD NOT pipeline requests using non-idempotent requestmethods or non-idempotent sequences of request methods (see Section2.1.2 of [Part2]). Otherwise, a premature termination of thetransport connection could lead to indeterminate results. A clientwishing to send a non-idempotent request SHOULD wait to send thatrequest until it has received the response status line for theprevious 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?