W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: Security of cross-origin pushed resources

From: Glen Knowles <gknowles@ieee.org>
Date: Sat, 21 Sep 2013 00:53:10 -0700
Message-ID: <CAJCH0yB0OE8hkh6o4H8vRDDvHDs3HKkA3O_MqfQBx4jgK_uBdg@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: William Chan (陈智昌) <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
We've developed several servers internally that, in addition to their main
job, operate as HTTP servers for monitoring and control. Since our
framework operates by duping and handing off sockets to processes based on
the type of service requested the HTTP support was implemented in the same
way, routing the socket to a process based on the host header. So if
requests to other vhosts are sent over the same socket they will arrive at
a process that has no way to deal with it.

I arrived at this model because 1) it was easy, 2) I could find no RFC that
addressed it, and 3) all the browser that I tested worked this way.

So there are at least some servers in the wild :)

As a counter example ARR (the Windows based load balancer bundled with IIS)
does multiplex requests of different hosts that resolved to the same
IP+port over shared TCP connections.

On Fri, Sep 20, 2013 at 10:36 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> On Sep 20, 2013, at 9:21 PM, William Chan (陈智昌) wrote:
> As usual, I feel like when you and I disagree on mailing lists, we spend
> many roundtrips just to find out that we misunderstood each other and we
> actually agree :)
> So, when I said "I'm supportive of changing the spec to remove
> cross-origin push for http URIs." I meant http:// scheme, and primarily I
> meant unauthenticated (I know that Patrick is hopeful we can authenticate
> and encrypt http:// URIs in the future, but when I say http:// scheme
> today, I mean unauthenticated). So no cert or anything.
> Does that clear it up? If not, then I think I don't understand or just
> actually disagree :P Do you think we need to change the existing text, and
> if so, what do you propose?
> http://http2.github.io/http2-spec/#rfc.section.10.1
> =====
> A server that is contacted using TLS is authenticated based on the
> certificate that it offers in the TLS handshake (see [RFC2818], Section 3).
> A server is considered authoritative for an "https" resource if it has been
> successfully authenticated for the domain part of the origin of the
> resource that it is providing.
> A server is considered authoritative for an "http" resource if the
> connection is established to a resolved IP address for the domain in the
> origin of the resource.
> A client MUST NOT use, in any way, resources provided by a server that is
> not authoritative for those resources.
> Umm, I hope folks realize that this last sentence forbids any
> form of hierarchical caching.
> ....Roy
Received on Saturday, 21 September 2013 07:53:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:15 UTC