Re: h2 requirements on authoritative responses

On Sep 2, 2014, at 5:22 PM, Martin Thomson wrote:

> On 2 September 2014 16:55, Martin Thomson <martin.thomson@gmail.com> wrote:
>> I'll send out proposed change sets once I've bashed on this a little
> 
> First, removal from 10.1:
> 
> REMOVE:
> -          A client is only able to accept HTTP/2 responses from
> servers that are authoritative for
> -          those resources.  This is particularly important for <xref
> target="PushResources">server
> -          push</xref>, where the client validates the
> <x:ref>PUSH_PROMISE</x:ref> before accepting
> -          the response.
> REMOVE:
> -          A client MUST discard responses provided by a server that
> is not authoritative for those
> -          resources.
> 
> Both of these statements simply aren't true in the proxy case.

+1

> Second, rewording 9.1.1 to allow for the proxy stuff:
> 
> OLD:
> -            Clients MAY use a single server connection to send
> requests for URIs with multiple
> -            different authority components as long as the server is <xref
> -            target="authority">authoritative</xref>.
> NEW:
> +            Connections that are made to origin servers without a
> proxy or tunnels created using the
> +            <xref target="CONNECT">CONNECT method</xref> MAY be
> reused for requests with multiple
> +            different URI authority components.  A connection can be
> reused as long as the server is
> +            <xref target="authority">authoritative</xref>.

A slight (editorial) suggestion:

  Connections that are made to an origin server, either directly or
  through a tunnel created using the <xref target="CONNECT">CONNECT method</xref>,
  MAY be reused for requests with different URI authority components
  if that origin server is also <xref target="authority">authoritative</xref>
  for those other authority components.

though this begs the question: why is this a MAY instead of a
MUST NOT ... unless X?

> KEEP:
>            For <spanx style="verb">http</spanx>
>             resources, this depends on the host having resolved to
> the same IP address.
> 
>             For <spanx style="verb">https</spanx> resources,
> connection reuse additionally depends
>             on having a certificate that is valid for the host in the URI.

+1

> OLD:
> -           That is the use of
> -            server certificate with multiple <spanx
> style="verb">subjectAltName</spanx> attributes,
> -            or names with wildcards.  For example, a certificate with a <spanx
> -            style="verb">subjectAltName</spanx> of <spanx
> style="verb">*.example.com</spanx> might
> -            permit the use of the same connection for <spanx
> style="verb">a.example.com</spanx> and
> -            <spanx style="verb">b.example.com</spanx>.
> NEW:
> +           That is the use of
> +            on having a certificate that is valid for the host in the
> URI.  A server might offer a
> +            certificate with multiple <spanx
> style="verb">subjectAltName</spanx> attributes, or
> +            names with wildcards, one of which is valid for the
> authority in the URI.  For example,
> +            a certificate with a <spanx
> style="verb">subjectAltName</spanx> of <spanx
> +            style="verb">*.example.com</spanx> might permit the use
> of the same connection for
> +            requests to URIs starting with <spanx
> style="verb">https://a.example.com/</spanx> and
> +            <spanx style="verb">https://b.example.com/</spanx>.

First sentence seems a bit garbled.  I suggest using "origin server" here
instead of server.

> KEEP:
>            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 <xref
> target="TLS-EXT">Server Name Indication
>             (SNI)</xref> extension to select  an origin server. This
> means that it is possible
>             for clients to send confidential information to servers
> that might not be the intended
> OLD:
> -            target for the request, even though the server has valid
> authentication credentials.
> NEW:
> +            target for the request, even though the server is
> otherwise authoritative.

+1

> ADD:
> +            A client that is configured to use a proxy directs
> requests to that proxy through a
> +            single connection.  That is, all requests sent via a
> proxy reuse the connection to the
> +            proxy.

In general, I don't think the protocol should specify such things.
A proxy might not even be using HTTP to its clients, for example.

> And I found some collateral in the description of push:
> 
> OLD:
> -            Clients receiving a pushed response MUST validate that
> the server is authoritative for
> -            it; see <xref target="authority"/>. For example, a server
> that offers a certificate for
> -            only the <spanx style="verb">example.com</spanx> DNS-ID
> or Common Name is not permitted
> -            to push a response for <spanx
> style="verb">https://www.example.org/doc</spanx>.
> NEW:
> +            Clients receiving a pushed response MUST validate that
> either the server is
> +            authoritative (see <xref target="authority"/>), or the
> proxy that provided the pushed
> +            response is configured for the corresponding request. For
> example, a server that offers
> +            a certificate for only the <spanx
> style="verb">example.com</spanx> DNS-ID or Common Name
> +            is not permitted to push a response for <spanx
> +            style="verb">https://www.example.org/doc</spanx>.

+1

Thanks,

....Roy

Received on Wednesday, 3 September 2014 20:32:31 UTC