Re: h2 requirements on authoritative responses

And the description of the renamed status code.

NEW:
+            The 421 (Misdirected Request) status code indicates that
the request was directed at a
+            server that is not able to produce a response.  This can
be sent by a server that is no
+            configured to produce responses for the combination of
scheme and authority that are^M
+            included in the request URI.

Which is all in the pull request that I'll merge as soon as I'm happy
that these won't immediately churn:

https://github.com/http2/http2-spec/pull/606


On 2 September 2014 16:55, Martin Thomson <martin.thomson@gmail.com> wrote:
> This is good feedback.  One consequence of inheriting SPDY was that
> there was a lot of effort put in there to avoid intermediation.  Some
> of this definitely shows in the form of "uncollected garbage", that is
> true.
>
> I'll send out proposed change sets once I've bashed on this a little
> so that everyone can review the changes more thoroughly.  I won't push
> this straight into the editor's copy until I'm satisfied that everyone
> is happy.
>
> On 31 August 2014 19:09, Roy T. Fielding <fielding@gbiv.com> wrote:
>> Note that the above forbids proxies.  A proxy is unlikely to be authoritative
>> for the resources that it is being used to proxy.
>
> That was not intentional.  I'll attempt to correct that.  I'm sure
> that I'll get it wrong at first.
>
>>>    For "https" resources, connection reuse additionally depends on
>>>    having a certificate that is valid for the host in the URI.  That is
>>>    the use of server certificate with multiple "subjectAltName"
>>>    attributes, or names with wildcards.  For example, a certificate with
>>>    a "subjectAltName" of "*.example.com" might permit the use of the
>>>    same connection for "a.example.com" and "b.example.com".
>>
>> Again, forbids making a connection to a proxy in order to have it make
>> an https request (e.g., CONNECT in section 8.3).
>
>> The above paragraphs need to be rewritten, perhaps by separating them
>> into separate sections on "how to make requests of an origin server"
>> and "how to make requests of a proxy". These requirements have little
>> to do with making a connection.
>
> I think that it's sufficient to talk about connection reuse outside of
> the proxy context.  That makes this a lot easier, I think.
>
>>>    In some deployments, reusing a connection for multiple origins can
>>>    result in requests being directed to the wrong origin server.  For
>>>    example, TLS termination might be performed by a middlebox that uses
>>>    the TLS Server Name Indication (SNI) [TLS-EXT] extension to select
>>>    the an origin server.  This means that it is possible for clients to
>>>    send confidential information to servers that might not be the
>>>    intended target for the request, even though the server has valid
>>>    authentication credentials.
>>
>> (editorial) "the an origin" -> "an origin".  I think this is an odd
>> discussion given that this section is not about TLS connections.
>
> A change in emphasis avoids that issue, I hope.
>
>>>    A server that does not wish clients to reuse connections can indicate
>>>    that it is not authoritative for a request by sending a 421 (Not
>>>    Authoritative) status code in response to the request (see
>>>    Section 9.1.2).
>>
>> That's not actually what it wants to say.  I have suggested
>> such a code before, though I called it 4xx Misdirected Request.
>
> I'll take that, "Not Authoritative" was only a name awaiting a
> suggestion like this.
>
> It will take a small amount of rewording to ensure that this is the
> emphasis, rather than on authority.
>
>>> 10.1.  Server Authority
>>>
>>>    A client is only able to accept HTTP/2 responses from servers that
>>>    are authoritative for those resources.  This is particularly
>>>    important for server push (Section 8.2), where the client validates
>>>    the PUSH_PROMISE before accepting the response.
>>
>> Again, explicitly forbids the use of proxies (and shared caches).
>> Repeated in section 10.4.
>>
>>>    HTTP/2 relies on the HTTP/1.1 definition of authority for determining
>>>    whether a server is authoritative in providing a given response, see
>>>    [RFC7230], Section 9.1.  This relies on local name resolution for the
>>>    "http" URI scheme, and the authenticated server identity for the
>>>    "https" scheme (see [RFC2818], Section 3).
>>>
>>>    A client MUST discard responses provided by a server that is not
>>>    authoritative for those resources.
>>
>> That was a limitation of SPDY, so I suspect this may be uncollected garbage.
>
> What a nice way of putting it.
>
> I've removed the paragraphs that I think were the cause of the
> offense, which should have no material impact on the interpretation of
> the document.

Received on Wednesday, 3 September 2014 19:46:06 UTC