Re: ORIGIN - suggested changes

[Stefan Eissing <[e-mail]>]

> Am 02.02.2017 um 02:30 schrieb Mark Nottingham <[e-mail]>:
> 
> 
>> On 2 Feb 2017, at 12:23 pm, Martin Thomson <[e-mail]> wrote:
>> 
>> On 2 February 2017 at 10:12, Mark Nottingham <[e-mail]> wrote:
>>> I don't buy the argument that removal itself adds complexity. Implementations already need to remember what origins they received a 421 for, so they already have the concept of origin set removal.
>> 
>> Well, you just established why it might be unnecessary.  The gain here
>> is in the client not sending a request to the wrong place.  But if
>> this is rare enough, then that cost is probably bearable.
> 
> Right, but the whole point of ORIGIN is to avoid those situations. 
> 
> 
>> The "everything except those" case doesn't concern me that much.
>> Iknow it's relatively common, but it is fairly rare that the set of
>> origins that are used is not easily enumerable, or incrementally
>> discoverable.
> 
> Spoken like a true browser vendor :) 
> 
> It'd be good to get a bit more data here from server-side folks. Anyone share this concern? I note that Nick seems to be OK with it.

The feedback from Apache httpd users which have wildcard cert setups is: do not enable h2. 

From their PoV, they have a config running with HTTP/1.1 for years now, enabled h2 and all hell broke lose. Some sites work, some don't and that also depends on what your browser did before *). They do not want to change their setups, they expect h2 to just work or they will not use it. 

Currently, ORIGIN frame is not supported by httpd. My expectation is, once added, by default the server would send an empty ORIGIN frame, implying that the current connection should only be used for the SNI host. If I read the current spec correctly. (And btw. which browser plans to support it?)

Additionally, having configuration directives per virtual host where an admin can add other ORIGINs for connections to this very host, seems a good first step. My goal is to have the default "just work" in case of wildcard certs and require intentional configuration by the admin to optimize from there.

The feedback I am receiving on 421 response and HTTP_1_1_REQUIRED handling is not great. And it's difficult to debug for most people.

Cheers, Stefan

*) httpd replies with HTTP_1_1_REQUIRED when a stream encounters a TLS setup for a site that is not the same as the current connection.

> Cheers,
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 

Stefan Eissing

<green/>bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de