Re: ORIGIN - suggested changes

[Stefan Eissing <[e-mail]>]

You are correct that the most frequent case is a 421 answer. The 1_1_REQUIRED is returned when the TLS layer detects a renegotiate attempt. Often, these are triggered by client certs, but some people seem to also require other ciphers in certain locations (don't ask my why).

I am not saying that all the confusion stems from HTTP/2. It's merely that the TLS+HTTP/1.1 combination made things possible that, at the moment, are not possible with h2. I know your and other peoples efforts to improve this. However until then, I'd like to offer a "safe" default in the server. I hope ORIGIN will allow me to do that.

> Am 02.02.2017 um 19:10 schrieb Mike Bishop <[e-mail]>:
> 
> That use of 1_1_REQUIRED surprises me; I would think 421 would be the appropriate response there, too, since the request needs to be made on a separate (but still HTTP/2) connection.
> 
> -----Original Message-----
> From: Stefan Eissing [mailto:[e-mail]] 
> Sent: Thursday, February 2, 2017 4:46 AM
> To: Mark Nottingham <[e-mail]>
> Cc: Martin Thomson <[e-mail]>; HTTP Working Group <[e-mail]>
> Subject: Re: ORIGIN - suggested changes
> 
> 
>> 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
> 
> 

Stefan Eissing

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