- From: David Morris <dwm@xpasc.com>
- Date: Tue, 2 Jul 2013 10:25:57 -0700 (PDT)
- To: HTTP Working Group <ietf-http-wg@w3.org>
On Tue, 2 Jul 2013, Sam Pullara wrote: > On Jul 2, 2013, at 9:52 AM, Martin Thomson <martin.thomson@gmail.com> wrote: > > On 2 July 2013 09:44, James M Snell <jasnell@gmail.com> wrote: > >> In other > >> words, we say that PUSH_PROMISE MUST NOT include :host or :scheme > >> and that clients MUST ignore them if they are sent. > > > > I don't like the prohibition because it's too simple. > > > > Say I do have, as Will points out, a forward proxy. One huge > > advantage that proxy could provide is push for cross-domain resources. > > Do you expect the proxy to parse the HTML of the initial request and > push down the resources that it finds in the document? I'm just > wondering what the implementation of this would look like. Why would the > client trust these resources are from the domains that the proxy claims? Clients must trust the proxy to deliver the initial page from the named host. Why shouldn't they trust the proxy to properly represent any PUSHed content's origin? In terms of figuring out associations of content to PUSH, it is reasonable for a proxy to remember the PUSHes it got from the origin server. In any case, I'm opposed to this 'simplification' because as already noted by other replies, it limits optimizations and isn't PUSH all about optimization. The multi-named department server was mentioned as a example where multiple host names share the same server. A very common example is the commerical shared hosting sites selling virtual servers for $5-10/month. With persistent connections today, the client manages shared connections which can be based on IP address (and is in at least one case I know well) or host name. We shouldn't be reducing that flexability. Dave Morris
Received on Tuesday, 2 July 2013 17:26:32 UTC