Re: HTTP/2.0 -04 candidate

On Tue, Jul 2, 2013 at 10:51 AM, James M Snell <jasnell@gmail.com> wrote:

> On Tue, Jul 2, 2013 at 10:25 AM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
> > On 2 July 2013 10:22, William Chan (陈智昌) <willchan@chromium.org> wrote:
> >> I don't understand why this proposal is an improvement.
> >
> > Me too :)
> >
>
> Which part?


> >> On Tue, Jul 2, 2013 at 10:15 AM, James M Snell <jasnell@gmail.com>
> wrote:
> >>> PUSH_PROMISE
> >>>     :path = http://someother.example.com/some-other-content.js
> >>>     push-authorization: {auth token of some sort}
> >>> 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.
> >
> > This in particular makes me queasy.  :scheme, :host and :path are so
> > 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.
>

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.