Re: h2 requirements on authoritative responses

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 Tuesday, 2 September 2014 23:56:17 UTC