RE: HTTP/2.0 -04 candidate

I know that there are proposals floating around to allow trusted cross-origin push in various ways, and that some browsers are more liberal than others in this regard under SPDY.  If we expect one of those to come up later, we shouldn't spec ourselves into a single-origin box early.

I think this hinges on the other discussion -- if we decide that PUSH_PROMISE contains only the headers that are different, we should be consistent and not include :scheme or :host if they aren't different for this resource.  If we decide that PUSH_PROMISE contains the full set of request headers, the discussion of which are mandatory is moot -- they'll always be there, because they're always required in request headers.

-----Original Message-----
From: Albert Lunde [mailto:atlunde@panix.com] 
Sent: Tuesday, July 2, 2013 6:22 AM
To: HTTP Working Group
Subject: Re: HTTP/2.0 -04 candidate

On 7/2/2013 12:22 AM, Sam Pullara wrote:
> It looks like that this could be an issue:
>
>     The header fields in PUSH_PROMISE MUST include the ":scheme", ":host"
>     and ":path" header fields that identify the resource that is being
>     pushed.  A PUSH_PROMISE always implies an HTTP method of GET.  If a
>     client receives a PUSH_PROMISE that does not include these header
>     fields, or a value for the ":method" header field, it MUST respond
>     with a stream error (Section 5.4.2  <http://tools.ietf.org/html/draft-unicorn-httpbis-http2-00#section-5.4.2>) of type PROTOCOL_ERROR.
 >
> I suggest that you limit to same origin and remove the :schema and the 
> :host. It is quite probable that a different host, even if could be 
> served from the same IP address, actually resolves to a different IP 
> address when the client resolves it. Even the same :host could resolve 
> to a different IP address.

A case where this could become less obvious might be a server or cluster of servers offering a number of name-based virtual hosts. It's fairly common for a virtual host to have two or four aliases.

Also, there may be shared resources the server knows about that aren't obviously related to a client's view of  "origins", like a host name used to serve particular media types or groups of content, such as shared styles, images, or sounds.

Received on Tuesday, 2 July 2013 14:01:26 UTC