Re: HTTP/2.0 -04 candidate

Yes, there are cases where the mechanism spec'd in SPDY today is
suboptimal. That seems like a poor reason to reject it, however, when the
alternative is guaranteed suboptimality.
-=R



On Tue, Jul 2, 2013 at 12:39 PM, Sam Pullara <spullara@gmail.com> wrote:

> On Jul 2, 2013, at 12:12 PM, David Morris <dwm@xpasc.com> wrote:
> >> Browsers associate security with the origin server. If I can serve
> >> content from an arbitrary origin that is a problem without trust.
> >> Rewriting the URLs with a different origin solves this problem and thus
> >> is not an issue.
> >
> > If the html from server: examplex.com as written references host:
> > x.example.com, and before delivering it, examplex.com rewrites it to
> > a url for examplex.com (in the html) and keeps track of the mapping so
> > that the PUSH_PROMISE knews where to get the content from, and serves
> > the other server's content, how is that not a bigger problem them
> > providing a PUSH_PROMISE with the correct identification?
>
> Because the browser gives it the security constraints of examplex.com and
> not x.example.com.
>
> >>> If we feel there is a security requirement here, it should be along
> >>> the lines of:
> >>>
> >>> The host name specified in a PUSH_PROMISE must have a DNS entry
> >>> which includes the IP address of server sending the PUSH_PROMISE.
>
> Many DNS servers only ship a subset of the IP addresses at a time,
> especially if there are lots of them.
>
> >>
> >> This would allow one domain on a VPS serve content for any other domain
> >> on a VPS.
> >
> > Exactly what happens with HTTP/1.1 virtual hosts. The TCP connection is
> > shared to serve data from multiple virtual hosts.
>
> In 1.1 I believe that you have separate connection per host name. Also,
> just because I am hosted on a VPS with hostname sam.vps.com doesn't mean
> I should be allowed to serve content as if it came from dave.vps.com.
> This may work for trusted forward proxies, but doesn't work in general.
>
> Sam
>
>
>
>
>