Re: h2 requirements on authoritative responses

Hi Roy,

I’ve reopened <https://github.com/http2/http2-spec/issues/413>, marked it editorial and linked to this.

Cheers,


On 1 Sep 2014, at 5:09 am, Roy T. Fielding <fielding@gbiv.com> wrote:

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

Well, it’s a MAY, not a MUST NOT — nothing is forbidden by the requirement above. Could it be written more helpfully? Sure.


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

--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 3 September 2014 06:30:25 UTC