h2 requirements on authoritative responses

This comment is in reference to sections 9.1.1-2, 10.1, and 10.4 of

http://tools.ietf.org/id/draft-ietf-httpbis-http2-14.txt

I don't know how much of this is just a remnant from SPDY or an
intention of the draft authors.  Proxies are considered by
most folks to be an important aspect of HTTP.  In general, it is
the responsibility of the client to decide whether it trusts a
proxy enough to make use of proxied responses.  If it doesn't,
it seems unlikely that the client would use the proxy to send requests.
It certainly doesn't make sense for the client to use a proxy for
requests if it also intends to discard the responses.

> 9.1.1.  Connection Reuse
> 
>    Clients MAY use a single server connection to send requests for URIs
>    with multiple different authority components as long as the server is
>    authoritative (Section 10.1).  For "http" resources, this depends on
>    the host having resolved to the same IP address.

Note that the above forbids proxies.  A proxy is unlikely to be authoritative
for the resources that it is being used to proxy.

>    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.

>    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 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.

> 9.1.2.  The 421 (Not Authoritative) Status Code
> 
>    The 421 (Not Authoritative) status code indicates that the current
>    origin server is not authoritative for the requested resource, in the
>    sense of [RFC7230], Section 9.1 (see also Section 10.1).
> 
>    Clients receiving a 421 (Not Authoritative) response from a server
>    MAY retry the request - whether the request method is idempotent or
>    not - over a different connection.  This is possible if a connection
>    is reused (Section 9.1.1) or if an alternative service is selected
>    ([ALT-SVC]).
> 
>    This status code MUST NOT be generated by proxies.
> 
>    A 421 response is cacheable by default; i.e., unless otherwise
>    indicated by the method definition or explicit cache controls (see
>    Section 4.2.2 of [RFC7234]).

Like I said, "Misdirected Request" is a better name for this code.


> 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.

*facepalm*

It is good to know when a response is authoritative (blessed or
generated by the origin) or not.  However, forbidding non-authoritative
responses is not (and has never been) a feature of HTTP.  Cached
responses, for example, are non-authoritative unless validated with
the origin server.  I will be somewhat bummed if HTTP/2 forbids
unvalidated caching.

That was a limitation of SPDY, so I suspect this may be uncollected garbage.


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <http://www.adobe.com/>

Received on Monday, 1 September 2014 02:09:37 UTC