Re: h2 requirements on authoritative responses

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.

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


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.

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.

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

I'll follow up with renaming of the status code.

Received on Wednesday, 3 September 2014 00:23:18 UTC