Re: ORIGIN - suggested changes

[Martin Thomson <[e-mail]>]

Inline.

On 2 February 2017 at 03:42, Ilari Liusvaara <[e-mail]> wrote:
>> You should do something about http:// resources.  This means that this
>> is a perfect http:// hijacking mechanism.  I don't think that was the
>> intent.  I would prefer if this were limited to HTTPS, which at least
>> leaves certificate validation.
>
> I thought this mechanism is strictly limited by the normal HTTP/2
> authoritativeness. Which impiles that it is only usable with
> certificate validation.

HTTP/2 defines authoritative for HTTP as well as HTTPS (leaning
heavily on the definitions in HTTP/1.1).  We often fall into the habit
of thinking that HTTP/2 implies HTTPS, but that's not how the
specification is written.

> I think server should start with resetting the list with whatever
> origins it is authoritative for. Especially in case client has some
> funny ideas about that (e.g. due to wildcard certificates[1]).

My hope is that there should be no need for a reset now that the
initial set only includes the SNI host.  The server merely has to make
claims about additional origins.  Once it does so, those funny ideas
go away.  Especially if ORIGIN can't express wildcards.

> You mean assuming that server can lose authoritativeness over an
> origin? Because once you assume that, the reset/remove operations
> folow with relatively little complexity.

The reason that I expect a server would want to disavow an origin
isn't anything to do with losing authoritativeness, but more with
operational constraints.  If the server is a gateway to multiple
back-ends and one of those back-ends wants to shift things around,
killing all affected connections is feasible, but a blunt instrument.

In any case, I think that this is rare enough not to warrant special
complexity in the specification to handle. And I mean any complexity
at all.

If the client determines that the server is no longer authoritative,
then the client stops sending requests over that connection.  That
doesn't need any extra signaling.

>> Let's say that if you want to start over, then you really start over:
>> make a new connection in that case.  The need to remove is greatly
>> diminished by starting with a very small set.  If you do need to
>> cleave off an origin after previously advertising it, then ALTSVC is
>> available and much more graceful than anything this provides.  Removal
>> - as specified - is still subject to races and therefore violence,
>> since there is no acknowledgment.
>
> The operation is just fundamentially racy, due to finite speed of
> light. And if you really wanted to (and I this is a bad idea), you
> could request ACK from client, even if ORIGIN didn't explicitly support
> ACKs.

That's my point, I don't think that we need to.  Any situation that
needs to happen immediately can be handled with a 421 (Not
Authoritative) status code.  For everything else, use ALTSVC.