Subject: HTTP/2.0 -04 candidate

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Jul 2013 17:23:12 -0700

Those people who volunteered to contribute to the layering work in the
SF interim have come up with something.  This includes a restructuring
of the content.

Since the changes are large in scope, we're not submitting this as
draft-ietf-httpbis-http2-04.  I've put this up as an individual
submission so that people can comment on structure, text, omissions:

 http://tools.ietf.org/html/draft-unicorn-httpbis-http2-00

Note: This is a proposal for the content of the
draft-ietf-httpbis-http2-04.  Please let us know - as soon as possible
- if the idea of this becoming a -04 offends you somehow.

This draft includes resolutions to all the issues on our milestone,
with the exception of two (#75: default priorities, #17: opaque data
in GOAWAY and RST_STREAM), which I plan to address tomorrow.

Now, most of the final pass is my fault (with a little help from the
github unicorn), so blame me for all the bad stuff and praise Jeff and
James for providing all the good stuff.

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 1 Jul 2013 18:22:14 -0700

How would you like editorial comments addressed?

Pull requests against the "layering" branch?

---

From: Patrick McManus <[email-masked]>
Date: Mon, 1 Jul 2013 21:35:05 -0400

> James for providing all the good stuff.
I think a thank you to all is in order.

---

From: Shigeki Ohtsu <[email-masked]>
Date: Tue, 02 Jul 2013 13:28:35 +0900

Thanks for your great work.

I've just read through the draft and submited a PR for some editrial fixes againt a layering branch.
https://github.com/http2/http2-spec/pull/157
Please review it. If the PR to the branch is not good for fix, pelase let me know it.

Regards,

---

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Jul 2013 21:37:30 -0700

Thanks, this was a bit rushed in parts so I potentially botched a few
edits. Pull requests much appreciated, especially for the small stuff.
On Jul 1, 2013 9:30 PM, "Shigeki Ohtsu" <[email-masked]> wrote:

> https://github.com/http2/**http2-spec/pull/157<https://github.com/http2/http2-spec/pull/157>
>>   http://tools.ietf.org/html/**draft-unicorn-httpbis-http2-00<http://tools.ietf.org/html/draft-unicorn-httpbis-http2-00>
>>

---

From: Sam Pullara <[email-masked]>
Date: Mon, 1 Jul 2013 22:22:58 -0700

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) 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. Also, do you really want the resource to use a different scheme than the original request? My suggestion on this is to limit PUSH_PROMISE to same origin and require only the :path header field to be set. Simplifies things quite a bit and the client should already know the :schema and :host header.

Sam

On Jul 1, 2013, at 9:37 PM, Martin Thomson <[email-masked]> wrote:

> Thanks, this was a bit rushed in parts so I potentially botched a few edits. Pull requests much appreciated, especially for the small stuff.
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Jul 2013 23:34:32 -0700

On 1 July 2013 22:22, Sam Pullara <[email-masked]> wrote:
> I suggest that you limit to same origin and remove the :schema and the
> :host.

You are probably right Sam, and I think that I agree, but this would
be a change and we need to be careful about that.  See
https://github.com/http2/http2-spec/issues/158

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Jul 2013 09:18:39 +0100

> https://github.com/http2/http2-spec/issues/158

I agree about being careful here.

Would this be the first case of the same origin policy (SOP)
being used within HTTP, or is that already done somewhere?

(I mean used within the HTTP protocol - SOP is a user agent
thing afaik, but its quite possible I don't know:-)

If this is the first time the SOP is being considered as a
part of the HTTP protocol, then I'd hope the wg consider whether
we want that to be baked in or not. I've no strong opinion, but
do wonder if the SOP as-is will make sense in 20 years time,
assuming that HTTP/2.0 will be in as long as HTTP/1 has been.
It could be that its better not baked in, or that it'd be
better to try generalise for example.

S.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 02 Jul 2013 08:52:41 -0400

+1

>> James for providing all the good stuff.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Albert Lunde <[email-masked]>
Date: Tue, 02 Jul 2013 08:21:34 -0500

On 7/2/2013 12:22 AM, Sam Pullara wrote:
>     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.
 >
> :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.

---

From: Mike Bishop <[email-masked]>
Date: Tue, 2 Jul 2013 13:59:56 +0000

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:[email-masked]] 
Sent: Tuesday, July 2, 2013 6:22 AM
To: HTTP Working Group
Subject: Re: HTTP/2.0 -04 candidate

> 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.

---

From: Mike Bishop <[email-masked]>
Date: Tue, 2 Jul 2013 15:42:49 +0000

From http://tools.ietf.org/html/draft-unicorn-httpbis-http2-00#section-6.6:
   The state of promised streams is bound to the state of the original
   associated stream on which the PUSH_PROMISE frame were sent.  If the
   originating stream state changes to fully closed, all associated
   promised streams fully close as well. [[anchor10: Ed.  Note: We need
   clarification on this point.  How synchronized are the lifecycles of
   streams and associated promised streams?]]

I thought previous on-list discussion had agreed to remove this tie between stream lifecycles and just send a stack of RST_STREAMs in a single packet if need be.  Is that still the consensus?

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, July 1, 2013 5:23 PM
To: HTTP Working Group
Subject: HTTP/2.0 -04 candidate

Those people who volunteered to contribute to the layering work in the SF interim have come up with something.  This includes a restructuring of the content.

Since the changes are large in scope, we're not submitting this as draft-ietf-httpbis-http2-04.  I've put this up as an individual submission so that people can comment on structure, text, omissions:

Note: This is a proposal for the content of the draft-ietf-httpbis-http2-04.  Please let us know - as soon as possible
- if the idea of this becoming a -04 offends you somehow.

This draft includes resolutions to all the issues on our milestone, with the exception of two (#75: default priorities, #17: opaque data in GOAWAY and RST_STREAM), which I plan to address tomorrow.

Now, most of the final pass is my fault (with a little help from the github unicorn), so blame me for all the bad stuff and praise Jeff and James for providing all the good stuff.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Jul 2013 08:55:40 -0700

> being used within HTTP, or is that already done somewhere?

Actually yes.  Sort of.  HTTPS (2818) only requires that a server
offer a certificate that contains the domain name (and chains to a
trusted issuer, etc...).  That means, that we're actually being MORE
restrictive by adding port to the set of things to check.

The only reason that this becomes an issue is server push (as above).
This does impose some constraints on implementations, but I'll refer
you to http://tools.ietf.org/html/draft-unicorn-httpbis-http2-00#section-10.3
where this is discussed.  10.1 touches on the issue as well, but I'm
less happy with that text.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Jul 2013 08:57:18 -0700

On 2 July 2013 06:21, Albert Lunde <[email-masked]> wrote:
> 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.

Name-based virtual hosting is a feature that I know some people want
to support, but HTTP/2.0 in its current form does not support that
feature.  As specified, name-based virtual hosting will depend on
having a connection for each name, the TLS SNI extension to select the
name and a matching certificate.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Jul 2013 09:02:16 -0700

> I thought previous on-list discussion had agreed to remove this tie between stream lifecycles and just send a stack of RST_STREAMs in a single packet if need be.  Is that still the consensus?

Mark?

I can't remember the state of this one.  I know that we discussed this
a couple of times, on-list and at-interim, but I don't recall a solid
conclusion.  (There might have been a weak conclusion.)

See http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/1115.html

---

From: James M Snell <[email-masked]>
Date: Tue, 2 Jul 2013 09:21:38 -0700

As far as I remember, yes, this should be changed. Pushed streams have to
be closed separately...that's why associated_only was suggested.
On Jul 2, 2013 9:04 AM, "Martin Thomson" <[email-masked]> wrote:

> > I thought previous on-list discussion had agreed to remove this tie
> between stream lifecycles and just send a stack of RST_STREAMs in a single
> packet if need be.  Is that still the consensus?
>
> Mark?
>

---

From: Sam Pullara <[email-masked]>
Date: Tue, 2 Jul 2013 09:29:27 -0700

> 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…

How would the client determine that the server is allowed to serve resources from another origin that doesn't resolve to the same IP address? Serving assets like JavaScript, Flash objects, Java applets, etc. from a particular origin has security implications for the client. Further, if this server can serve it, is there any reason for another origin to be used? Different origins were used in the past for a wide variety of reasons but the most obvious one is that the main origin doesn't have the asset, secondarily to increase concurrency in HTTP/1.1. HTTP/2.0  should get rid of the idea that you need a bunch of different host names to optimally serve your pages that have a lot of resources on them since you only need one connection and they can be muxed together.

Sam

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 2 Jul 2013 09:42:45 -0700

There are other reasons to have different host names other than just name
sharding to increase parallelism. I do hope that they will be reduced in a
HTTP/2 world, but I expect them to still exist and it seems reasonable to
try to share connections where advantageous to do so.

Moreover, consider HTTP forward proxies. Browsers today can explicitly
configure them, or rely on PAC scripts to specify such proxies. These
proxies can serve resources for different origins over the same proxy
connection (although they cannot be multiplexed in HTTP/1.X). I don't see
why we would want to remove that capability in HTTP/2.

On Tue, Jul 2, 2013 at 9:29 AM, Sam Pullara <[email-masked]> wrote:

> 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.
>
> How would the client determine that the server is allowed to serve
> resources from another origin that doesn't resolve to the same IP address?
> Serving assets like JavaScript, Flash objects, Java applets, etc. from a
> particular origin has security implications for the client. Further, if
> this server can serve it, is there any reason for another origin to be
> used? Different origins were used in the past for a wide variety of reasons
> but the most obvious one is that the main origin doesn't have the asset,
> secondarily to increase concurrency in HTTP/1.1. HTTP/2.0  should get rid
> of the idea that you need a bunch of different host names to optimally
> serve your pages that have a lot of resources on them since you only need
> one connection and they can be muxed together.
>
> Sam
>
>
>

---

From: Albert Lunde <[email-masked]>
Date: Tue, 02 Jul 2013 11:43:46 -0500

> name and a matching certificate.

Part of that restriction is based on the (intended) properties of TLS, 
and thus HTTPS.

Is the something about HTTP/2.0 that rules out name-based virtual 
hosting on port 80, as practiced with HTTP/1.1, or is this just a 
restriction of what kind of requests can be multiplexed on one TCP 
connection?

A concrete use case I can think of would be pushing out image and style 
files used in the standard organization style. A different use case 
would be referencing URLs from a content distribution network.

(I used to run a Apache server that was the "web server of last resort" 
for a number of university departments, with about a hundred virtual 
host names.)

-- 
     Albert Lunde  [email-masked]
                   [email-masked]  (address for personal mail)

---

From: James M Snell <[email-masked]>
Date: Tue, 2 Jul 2013 09:44:16 -0700

Thinking it through, omitting the host and scheme from a push_promise
makes the most sense for a number of reasons...

Logically, this is *server push*. The server is ultimately determining
where the content comes from. It could just as easily do a GET to some
other domain and push that to the client as if it were actually hosted
locally... the point is, the client doesn't really care. It sends a
single request to A Host, get's N-responses back from that Host. It
ought to be naturally assumed that the pushed content is associated
with the same host the original request was directed to. In other
words, we say that PUSH_PROMISE MUST NOT include :host or :scheme
and that clients MUST ignore them if they are sent.

So.. a client sends...

HEADERS
  + END_STREAM
     :method = GET
     :host = example.org
     :scheme = http
     :path = /foo/bar/baz

The server responds with...

HEADERS
  - END_STREAM
    :status = 200
    content-type: text/html
    content-length: 123

PUSH_PROMISE
    :method = GET
    :path = /foo/images/a.png

PUSH_PROMISE
    :method = GET
    :path = /foo/images/b.png

DATA
  + END_STREAM

The :host and :scheme for the two promised implied GETS are
example.org and http. If the server wishes to indicate that the
content actually lives somewhere else, it can include a
Content-Location header in the HEADERS of the two pushed streams.

This approach feels natural and simple, without introducing the need
for same-origin complexity.

- James

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Jul 2013 09:52:43 -0700

On 2 July 2013 09:44, James M Snell <[email-masked]> wrote:
> In other

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.

Or, say we do provide features for virtual hosting that would allow a
CDN or aggregated hosting arrangement to become "authoritative" for
multiple names.

The current text says something like "make sure the server is allowed
to push".  Which permits both kinds of arrangement.  Reducing the
mandatory set of headers to just ":path" would be enough, I think.
Prohibiting the others might be over-rotating.

---

From: Sam Pullara <[email-masked]>
Date: Tue, 2 Jul 2013 09:56:16 -0700

> 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?

Sam

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 2 Jul 2013 10:05:32 -0700

From
http://www.techradar.com/us/news/internet/how-the-amazon-silk-browser-works-1036102
:
"""
Another interesting trick: Silk keeps track of this parsing. Jenkins says
Silk can keep track of how the processing worked for, say, the last 100,000
users - that in all cases, the same logo header was downloaded and that the
page did not change this routine. When you visit using the browser, Silk
might decide to use a "smart push" and send you that logo header to speed
up browsing even further.
"""

As far as trust, a browser will trust an explicitly configured forward
proxy for http:// resources. For https://, we will tunnel through with
CONNECT and do SSL to the origin over the tunnel.

On Tue, Jul 2, 2013 at 9:56 AM, Sam Pullara <[email-masked]> wrote:

> 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?
>
> Sam
>
>
>

---

From: Sam Pullara <[email-masked]>
Date: Tue, 2 Jul 2013 10:09:36 -0700

On Jul 2, 2013, at 10:05 AM, William Chan (陈智昌) <[email-masked]> wrote:
> From http://www.techradar.com/us/news/internet/how-the-amazon-silk-browser-works-1036102:
> """
> Another interesting trick: Silk keeps track of this parsing. Jenkins says Silk can keep track of how the processing worked for, say, the last 100,000 users - that in all cases, the same logo header was downloaded and that the page did not change this routine. When you visit using the browser, Silk might decide to use a "smart push" and send you that logo header to speed up browsing even further.
> """
> 
> As far as trust, a browser will trust an explicitly configured forward proxy for http:// resources. For https://, we will tunnel through with CONNECT and do SSL to the origin over the tunnel.

Got my forward and reverse proxy confused. Makes sense for HTTP with a trusted forward proxy — however, that doesn't mean that every HTTP connection should be able to send HTTP resources for any URL. This seems like it should be limited to trusted forward proxies and only over HTTP.

Sam

---

From: James M Snell <[email-masked]>
Date: Tue, 2 Jul 2013 10:15:33 -0700

> advantage that proxy could provide is push for cross-domain resources.

The prohibition does not eliminate this possibility, not by any
stretch. Remember, we still also have Content-Location that we can
play with here... and there is plenty of room for experimentation with
other new kinds of response headers that could be used to indicate
that one domain has given another domain permission to push it's
content.

For instance, let's consider your push proxy pushing content for
cross-domain resources...

The proxy receives a GET from the client for domain example.org and
decides that it is going to push content from someother.example.com...
One (quick strawman) approach to allow for this would be something
like:

PUSH_PROMISE
    :path = http://someother.example.com/some-other-content.js
    push-authorization: {auth token of some sort}

When the client receives this, the :scheme and :host still point to
example.org, but because the :path contains a full URL, the client can
easily detect that the proxy is attempting to push content for another
domain. The hypothetical push-authorization header (defined as a
request header for the purposes of push_promise) would include a token
issued by someother.example.com that the client can use to verify that
example.org is allowed to push that content.

Now, this is just a strawman example, but it demonstrates that we can
achieve the cross-domain push while still having the No :host or
:scheme in PUSH_PROMISE restriction.

> Prohibiting the others might be over-rotating.

In general, I have a challenge making statements like "make sure the
server is allowed to push" without defining (or referring to) any
means of actually performing that verification... but ah well...

Perhaps a bit of a compromise... for now, can we say for now that *If*
the PUSH_PROMISE contains a :host and :scheme it SHOULD be the same as
the originating request and say further that a client SHOULD NOT
accept a push with a different :host and :scheme unless it can verify
(via currently unspecified means) that the originating domain has
permission to push that content.

Yes, it's close to the original language but uses SHOULD and SHOULD
NOT to hopefully make things quite a bit stronger. I'm definitely +1
on saying that only :path is required in PUSH_PROMISE tho, and that if
:scheme and :host are omitted, they are inherited from the originating
request.

Does that work better?

---

From: Roberto Peon <[email-masked]>
Date: Tue, 2 Jul 2013 10:19:23 -0700

As is done with SPDY today:
If the cert matches, and the DNS resolution for the hostname includes the
IP to which a preexisting connection is connected, then that connection can
be shared.

In many cases, different hosts are used as a workaround for the max
concurrency limit in http/1.x. Right now this is suboptimal for http/2, as
it must do a DNS lookup to determine if it can share the connection. Things
begin to change from suboptimal to bad when you force http/2 to make as
many connections as http/1 (all because the site was smart and did domain
sharding to optimize http/1.x traffic).

Right now there is no way for the client to share a connection between
hosts where the DNS resolutions don't overlap.

None of this changes the same origin policies at the HTTP semantic layers--
this is purely a session layer thing.

-=R

---

From: Roberto Peon <[email-masked]>
Date: Tue, 2 Jul 2013 10:20:34 -0700

++

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 2 Jul 2013 10:22:03 -0700

I don't understand why this proposal is an improvement.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Jul 2013 10:25:49 -0700

> I don't understand why this proposal is an improvement.

Me too :)

>> :scheme in PUSH_PROMISE restriction.

This in particular makes me queasy.  :scheme, :host and :path are so
simple.  Please don't mess them up further.

>> means of actually performing that verification... but ah well...

That's OK, because we do define the rules.  See Section 10.1:

http://tools.ietf.org/html/draft-unicorn-httpbis-http2-00#section-10.1

---

From: David Morris <[email-masked]>
Date: Tue, 2 Jul 2013 10:25:57 -0700 (PDT)

On Tue, 2 Jul 2013, Sam Pullara wrote:

> 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

---

From: David Morris <[email-masked]>
Date: Tue, 2 Jul 2013 10:36:18 -0700 (PDT)

On Tue, 2 Jul 2013, Sam Pullara wrote:

> On Jul 2, 2013, at 10:05 AM, William Chan (???) <[email-masked]> wrote:
> > From 
> > http://www.techradar.com/us/news/internet/how-the-amazon-silk-browser-works-1036102:
> > """ Another interesting trick: Silk keeps track of this parsing.
> > Jenkins says Silk can keep track of how the processing worked for,
> > say, the last 100,000 users - that in all cases, the same logo header
> > was downloaded and that the page did not change this routine. When you
> > visit using the browser, Silk might decide to use a "smart push" and
> > send you that logo header to speed up browsing even further. """
> > 
> Got my forward and reverse proxy confused. Makes sense for HTTP with a
> trusted forward proxy ? however, that doesn't mean that every HTTP
> connection should be able to send HTTP resources for any URL. This seems
> like it should be limited to trusted forward proxies and only over HTTP.

Reverse proxies are invisible to the client. Any trust issue is the same
whether one connection or multiple connections are used when traffic
ends up at the reverse proxy.

There is a fundamental flaw in the orgin server security, if you can
trust the server to deliver the original resource but can't trust it
to deliver any pushed content referenced by that page. After all, if
the server owner wants to break trust, it can just rewrite all the
URLs in the base resource to refrence itself and then proxy the
content which isn't local.

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.

This doesn't apply to visible proxies.

---

From: David Morris <[email-masked]>
Date: Tue, 2 Jul 2013 10:39:51 -0700 (PDT)

> > Prohibiting the others might be over-rotating.

Um, this is getting complicated with no security value. The :path
header now is more complex to parse and hence may encounter more
errors.

---

From: Sam Pullara <[email-masked]>
Date: Tue, 2 Jul 2013 10:44:01 -0700

> content which isn't local.

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.

>  which includes the IP address of server sending the PUSH_PROMISE.

This would allow one domain on a VPS serve content for any other domain on a VPS.

Sam

---

From: James M Snell <[email-masked]>
Date: Tue, 2 Jul 2013 10:51:22 -0700

>> I don't understand why this proposal is an improvement.

Which part?

> simple.  Please don't mess them up further.

Please do keep in mind that the particular part above wasn't a
proposal, I very clearly indicated that it was just a quickly written
strawman example illustrating a point.

To be clear, the proposal I made was:

1. Only require :path (and :method) in PUSH_PROMISE
2. If :scheme and :host are not provided, inherit the ones from the
originating request
3. If :scheme and :host are provided, they SHOULD match from the
originating request

This would simplify the requirements for push promise and make
same-origin the default while giving room to experiment with other
options later.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 2 Jul 2013 12:08:27 -0700

> same-origin the default while giving room to experiment with other

Can you clarify what the wins are here? Here's what I can see:
* Saves the origin server from having to remember the scheme & host. But
doesn't it have to know them anyway?
* Saves emitting the scheme and host on the wire. Header compression means
this is a pretty minimal advantage.
* Simpler spec-wise? I think if we were able to require same origin, then
it'd be simpler. But given the reasons for not simply requiring same
origin, I think this is just a tradeoff to simplify the common case but add
more text that makes the edge cases more easily forgettable. And we can
argue about that to no end, so I am just going to chalk it up as unclear
win/loss.

Here are the losses:
* Intermediaries need to track the headers for the originating request in
order to fully identify the pushed resource
* Uses a SHOULD to recommend against stuff that is not uncommonly done. For
example, Silk browser and Chrome on mobile both may push cross origin
resources -
https://code.google.com/p/chromium/codesearch#chromium/src/net/spdy/spdy_session.cc&q=spdy_session.cc&sq=package:chromium&l=1764
.
* Uses a SHOULD to recommend against behavior that there has been some mild
interest in, namely mixed content (different schemes) over the same HTTP/2
connection via mechanisms like Alternate-Protocol, which both Firefox and
Chromium support today using an encrypted (but perhaps unauthenticated)
SPDY session.
* Uses a SHOULD to recommend against cross-origin push that services (e.g.
CDNs) with many virtual hosts may want to leverage. We've been discussing
pushing the redirected response, even if the redirect is cross-origin,
which may happen in Set-Cookie flows.

I feel the proposed changes have ambiguous benefit, and they marginalize
existing SPDY use cases and likely future HTTP/2 use cases. Thus, I do not
support this proposal.

---

From: David Morris <[email-masked]>
Date: Tue, 2 Jul 2013 12:12:54 -0700 (PDT)

On Tue, 2 Jul 2013, Sam Pullara 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?

> This would allow one domain on a VPS serve content for any other domain 

Exactly what happens with HTTP/1.1 virtual hosts. The TCP connection is
shared to serve data from multiple virtual hosts.

I don't see this as a problem that needs to be prevented. If the
PUSH_PROMISE doesn't make the offer, all that will happen is that
the client will notice the common IP and make the request itself.
All to negate the advantage of the PUSH methodology.

---

From: "Ludin, Stephen" <[email-masked]>
Date: Tue, 2 Jul 2013 13:28:45 -0600

>All to negate the advantage of the PUSH methodology.

We also have to consider cases where load balancers and mapping systems
will provide ever rotating DNS resolutions and the resolution of a DNS
name to a set of IPs does not necessarily mean there are not other valid
IPs for that domain.  It seems like the suggestion is:

CLIENT:
- Resolves domain1.com to ip set {1,2,3} ( for eg. )
- Sends request

SERVER
- Receives request for :host domain1.com
- Sends PUSH_PROMISE for :host domain2.com

CLIENT
- Receive PUSH_PROMISE for domain2.com
- Resolves domain2.com
- If resolution of domain2.com is not in set {1,2,3} reset the stream

Do I have that correct?  If so, then I think we will run into a lot of
problems around matching the resolution of domain2.com to the IP set for
domain1.com.  This is not an uncommon scenario for Akamai at least.  All
this means is coming up with a security requirement that leaves the
feature useful is going to be tricky.

-stephen

---

From: Sam Pullara <[email-masked]>
Date: Tue, 2 Jul 2013 12:39:59 -0700

> providing a PUSH_PROMISE with the correct identification?

Because the browser gives it the security constraints of examplex.com and not x.example.com.

>>> 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.

> 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

---

From: Roberto Peon <[email-masked]>
Date: Tue, 2 Jul 2013 12:49:14 -0700

Assuming that the IPs are mostly in the RRSET, so long as any IP from the
resolution (which is actually hostname -> RRSET, as opposed to hostname ->
IP as many (including me normally) forget), this may be a smaller problem
than you think.

Of course, that all depends on how stable the RRSETs are, and I don't know
about Akamai's RRSET stability!
-=R

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Jul 2013 12:51:36 -0700

> feature useful is going to be tricky.

Yes, the implementation Roberto describes will break in those sorts of
scenarios.  That's why we're not doing this yet, I think.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 2 Jul 2013 12:51:50 -0700

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 <[email-masked]> wrote:

> 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
>
>
>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Jul 2013 12:55:42 -0700

On 2 July 2013 12:51, Roberto Peon <[email-masked]> wrote:
> 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.

That's true, the coalescing that SPDY does won't work 100% of the
time, but the times where it does work will make (most) things better.
 If by better you mean fewer connections - and we're fairly sure that
is actually better.

---

From: Mike Belshe <[email-masked]>
Date: Tue, 2 Jul 2013 13:11:29 -0700

Sam is right on this point.  The original spdy spec said this:

"Browsers receiving a pushed response MUST validate that the server is
authorized to push the URL using the browser
same-origin<http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml#RFC6454>
policy.
For example, a SPDY connection to www.foo.com is generally not permitted to
push a response for www.evil.com."

Even if the servers are required not to send promises for resources they
don't technically own, browsers need to verify it.  The client will be in
the enforcement role here.

Mike

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 2 Jul 2013 14:27:38 -0700

Yes, any client that cares about security will do the enforcement
regardless. The thing is there are two new proposals on the table here.
Sam's proposal is to simply drop :scheme and :host and always assume same
origin. James' modification is to assume same origin unless otherwise
specified. I prefer the status quo of explicitly specifying the headers.
And I think that unless there are compelling reasons to *change* the spec,
we should opt to keep it as is. Do people feel strongly that we should
adopt either Sam or James' proposals for the implementation draft?

On Tue, Jul 2, 2013 at 1:11 PM, Mike Belshe <[email-masked]> wrote:

> authorized to push the URL using the browser same-origin<http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml#RFC6454> policy.
> For example, a SPDY connection to www.foo.com is generally not permitted
> to push a response for www.evil.com."
>

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 03 Jul 2013 09:44:24 +1200

On 3/07/2013 9:27 a.m., William Chan (陈智昌) wrote:
> regardless. The thing is there are two new proposals on the table 
> here. Sam's proposal is to simply drop :scheme and :host and always 
> assume same origin. James' modification is to assume same origin 
> unless otherwise specified. I prefer the status quo of explicitly 
> specifying the headers. And I think that unless there are compelling 
> reasons to *change* the spec, we should opt to keep it as is. Do 
> people feel strongly that we should adopt either Sam or James' 
> proposals for the implementation draft?

For this draft. No.

Amos

---

From: David Morris <[email-masked]>
Date: Tue, 2 Jul 2013 15:25:38 -0700 (PDT)

To be clear ... I feel stongly that the spec shouldn't change.

---

From: "Ludin, Stephen" <[email-masked]>
Date: Tue, 2 Jul 2013 19:02:00 -0500

>scenarios.  That's why we're not doing this yet, I think.

I concur with the other strand of this thread which seems to be coming to
consensus that this is a 'not in the is draft' feature at least.  That
said, I am certainly interested in kicking this around more and coming up
with a workable solution.  It could be that 'same origin' is the
best/safest we can do, but the potential advantages of pushing additional
related resources not on the same domain down the session is very
appealing.

Here is an idea to chew on.  It has been discussed before, but if there
was a concept of returning multiple certs in the ServerHello which
indicate other common names the origin is authorized to serve I tight
provide a path forward to serving related content from those domains.  For
example, if the origin serves an html response on domain1.com which has
references to objects on otherdomain.com AND the origin has a valid
certificate for otherdomain.com it has a mechanism to 'prove' to the
client that it is authorized to push that content.

At this point I am rewriting TLS as well as getting far from the original
subject.  Probably best to continue in a fresh thread if there is interest.

-stephen

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 2 Jul 2013 17:11:07 -0700

This is something we're pursuing in the next version of SPDY. We haven't
pushed it forward in httpbis because it's half-baked, and our typical
strategy has been to say "yo dawgs, we're interested this area and
exploring it. we'll experiment and report back when we have something
concrete and data to support." This is one reason we've defined a
CREDENTIAL frame in SPDY, and we're talking about pushing DNS info in a new
frame type as well to support this stuff.

But yeah, as you say, we should fork a thread to discuss if interested. I
don't know if folks would rather us discuss it here, or rather the SPDY
folks go off and get impl experience first and report back. Within SPDY
land, we're going to experiment with this no matter what and depending on
how successful that is, come back and discuss here.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 2 Jul 2013 17:15:13 -0700

Actually in this case I'm worried about latency more than the cost of
additional connections!
I don't want to spend the extra RTs necessary to set up additional (and not
that useful) SSL connections if it is avoidable.
Requiring that would make HTTP/2.0 significantly slower than HTTP/1 in many
cases where domain sharding has been used. :(
-=R

On Tue, Jul 2, 2013 at 12:55 PM, Martin Thomson <[email-masked]>wrote:

> suboptimal.

---

From: "Ludin, Stephen" <[email-masked]>
Date: Tue, 2 Jul 2013 19:18:12 -0500

Agreed 100%.  Let's discuss more in SPDY land.

-stephen

From: Roberto Peon <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 2, 2013 5:15 PM
To: Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: Sam Pullara <[email-masked]<mailto:[email-masked]>>, HTTP Working Group <[email-masked]<mailto:[email-masked]>>
Subject: Re: HTTP/2.0 -04 candidate
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-Date: Tuesday, July 2, 2013 5:15 PM

Actually in this case I'm worried about latency more than the cost of additional connections!
I don't want to spend the extra RTs necessary to set up additional (and not that useful) SSL connections if it is avoidable.
Requiring that would make HTTP/2.0 significantly slower than HTTP/1 in many cases where domain sharding has been used. :(
-=R

On Tue, Jul 2, 2013 at 12:55 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 2 Jul 2013 17:18:27 -0700

I'm not as concerned about this, because I'm optimistically thinking more
long-term and envisioning a world where domain sharding hacks are a thing
of the past. Yeah, we're a long ways off still. But I'm still beating the
drums as long as I can to get people to deprecate those hacks.

On Tue, Jul 2, 2013 at 5:15 PM, Roberto Peon <[email-masked]> wrote:

> I don't want to spend the extra RTs necessary to set up additional (and
> not that useful) SSL connections if it is avoidable.
> Requiring that would make HTTP/2.0 significantly slower than HTTP/1 in
> many cases where domain sharding has been used. :(
> -=R
>
>

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 2 Jul 2013 17:47:15 -0700

partial ThreadJack:

Can we get a draft-unicorn-httpbis-http2-01 published with all the changes
that were merged over the past day? Don't want to burden but given we have
2 days until the -04 release I'm hoping the slightly faster iteration pace
is ok.

On Tue, Jul 2, 2013 at 5:18 PM, William Chan (陈智昌) <[email-masked]>wrote:

>> On Tue, Jul 2, 2013 at 12:55 PM, Martin Thomson <[email-masked]
>> > wrote:
>>

---

From: James M Snell <[email-masked]>
Date: Tue, 2 Jul 2013 18:23:12 -0700

+1
On Jul 2, 2013 5:48 PM, "Jeff Pinner" <[email-masked]> wrote:

>>> On Tue, Jul 2, 2013 at 12:55 PM, Martin Thomson <
>>> [email-masked]> wrote:
>>>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Jul 2013 20:19:47 -0700

If it can wait until tomorrow morning, that would be good.  I've got
fixes for the last issues from Alexey and Hasan inbound, but I'm not
in a position to do anything significant at home since my machine
died.

I talked to Mark earlier and it might be that we miss the July 4
deadline, to allow folks a little more time to assimilate these edits.

(If this can wait another 12 hours, I can excise the associated stream
reset bug at the same time.)

On 2 July 2013 18:23, James M Snell <[email-masked]> wrote:
>> that were merged over the past day? Don't want to burden but given we have 2
>> days until the -04 release I'm hoping the slightly faster iteration pace is
>> ok.
>>
>>
>>> long-term and envisioning a world where domain sharding hacks are a thing of
>>> the past. Yeah, we're a long ways off still. But I'm still beating the drums
>>> as long as I can to get people to deprecate those hacks.
>>>
>>>
>>>> On Tue, Jul 2, 2013 at 12:55 PM, Martin Thomson

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 2 Jul 2013 20:32:45 -0700

Tomorrow morning is perfect -- thanks for all your hard work!

On Tue, Jul 2, 2013 at 8:19 PM, Martin Thomson <[email-masked]>wrote:

> >> On Tue, Jul 2, 2013 at 5:18 PM, William Chan (陈智昌) <
> [email-masked]>
> >> wrote:
> >>>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Jul 2013 07:33:06 +0000

> subject.  Probably best to continue in a fresh thread if there is interest.

Hi Stephen.

This is authorization at the HTTP level. I don't think this should go in TLS just because TLS has a mechanism for showing certificates. Also if you do want it to go in TLS, there's an RFC for that: http://tools.ietf.org/html/rfc5878 . This allows for sending arbitrary authorization information.

Alternatively, you could add this in HTTP as a header or as a new frame type.

Yoav

---

From: Albert Lunde <[email-masked]>
Date: Wed, 03 Jul 2013 07:12:55 -0500

It seems like the two dimensions of the problem of virtual hosting are 
alternate names for the same content and multiple sites with different 
content sharing the same server.

On 7/3/2013 2:33 AM, Yoav Nir wrote:
>> provide a path forward to serving related content from those domains.
[...]
> Alternatively, you could add this in HTTP as a header or as a new frame type.

If an objective is to develop a protocol for doing something like 
"name-based virtual hosting" with TLS server certificates, there are two 
dimensions to try to capture. One is the analog of aliases for a given 
site name, the other is the distinct virtual-hosted sites being offered.

For the first dimension, the subject alternate name certificate 
extension is a pretty good fit. If I want to say that 
www.chemistry.example.edu, chemistry.example.edu, 
www.alchemy.example.edu, and alchemy.example.edu are, in effect, aliases 
for the same content, then a server certificate with a list of subject 
alternate names, seems pretty much on target.

This second dimension is the sticky problem. Two approaches in use today 
are to put each site and its certificate on a distinct IP address (which 
is what name based virtual hosting was trying to avoid), another is to 
create a single certificate with a long list of subject alternate names 
or a wildcard certificate.

We've got at least one college at my university which routinely creates 
virtual hosts for every department (on port 80), and there is the 
commercial analog where completely different enterprises, with distinct 
content, are virtual hosted on the same server.

Lumping all the sites into one certificate might work for different 
college departments sharing the same information technology staff, but 
it's not going to scale well, or work, for the case of independent 
entities trying to share the same web hosting service.

I suppose you don't want to attack that problem right now (in this draft).

(I am also skeptical that the whole "same origin" model as variously 
constructed for cookies, Flash, JavaScript, etc. really provides much 
security, to them, today, but that's another question.)

---

From: "Ludin, Stephen" <[email-masked]>
Date: Wed, 3 Jul 2013 09:43:23 -0500

Zero intention of doing so. The "rewrite TLS" comment was there simply to
point out how far afield the idea was going.  For the record, I am open to
most any ideas but my goal was not to suggest we tweak TLS but more to
point out a potential direction to spur more conversation.  Will and
Roberto handily redirected the conversation to the experimental SPDY world.

Thanks for the pointer to the RFC and the other suggestions!

-stephen  

On 7/3/13 12:33 AM, "Yoav Nir" <[email-masked]> wrote:

>>For
>This is authorization at the HTTP level. I don't think this should go in
>TLS just because TLS has a mechanism for showing certificates. Also if
>you do want it to go in TLS, there's an RFC for that:
>http://tools.ietf.org/html/rfc5878 . This allows for sending arbitrary
>authorization information.
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Jul 2013 10:42:39 -0700

> I thought previous on-list discussion had agreed to remove this tie between stream lifecycles and just send a stack of RST_STREAMs in a single packet if need be.  Is that still the consensus?

This is removed from the new version of the draft.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Jul 2013 20:50:16 +0000

I should add that this RFC I mentioned is problematic as there are IPR claims. 

Yoav