Subject: HTTP/2 and non-authoritative pushes

From: Mike Bishop <[email-masked]>
Date: Tue, 14 Apr 2020 19:39:18 +0000

Secondary Certs issue #1088 leads back to an interesting bit in RFC7540.  Section 8.2 says:

   The server MUST include a value in the ":authority" pseudo-header

   field for which the server is authoritative (see Section 10.1<https://tools.ietf.org/html/rfc7540#section-10.1>).  A

   client MUST treat a PUSH_PROMISE for which the server is not

   authoritative as a stream error (Section 5.4.2<https://tools.ietf.org/html/rfc7540#section-5.4.2>) of type

   PROTOCOL_ERROR.

Note that it doesn't explicitly say which stream should be treated as being in error.  The simplest reading, since it's an invalid PUSH_PROMISE, would be the stream on which the PUSH_PROMISE was sent.  However, the server and the client might not have the same view of what origins the server is authoritative for, for various reasons.  Given that, blowing up the parent request because of an invalid PUSH_PROMISE seems completely unreasonable as a response.  Should this indicate that it's a stream error on the promised stream?

(In Secondary Certs, the draft currently requires that the server have sent the certificate for the origin it wants to push for prior to pushing content, and violation of that is a connection error.  That doubly seems excessive, and I'll change that in a PR shortly.)

---

From: Ted Hardie <[email-masked]>
Date: Tue, 14 Apr 2020 13:07:40 -0700

On Tue, Apr 14, 2020 at 12:42 PM Mike Bishop <[email-masked]> wrote:

>    field for which the server is authoritative (see Section 10.1 <https://tools.ietf.org/html/rfc7540#section-10.1>).  A
>
>    authoritative as a stream error (Section 5.4.2 <https://tools.ietf.org/html/rfc7540#section-5.4.2>) of type
>
>    PROTOCOL_ERROR.
>
>
>
> Note that it doesn’t explicitly say which stream should be treated as
> being in error.  The simplest reading, since it’s an invalid PUSH_PROMISE,
> would be the stream on which the PUSH_PROMISE was sent.  However, the
> server and the client might not have the same view of what origins the
> server is authoritative for, for various reasons.  Given that, blowing up
> the *parent* request because of an invalid PUSH_PROMISE seems completely
> unreasonable as a response.  Should this indicate that it’s a stream error
> on the promised stream?
>

I think that would be in-line with the list discussion we had in the
context of (rejected) erratum 4535
<https://www.rfc-editor.org/errata/rfc7540>
That was not, sadly, captured with the erratum, but generally was inline
with the reading that an invalid action by the parent blows up the child
stream, not the parent (at least that's my reading).

Ted

>
> (In Secondary Certs, the draft currently requires that the server have
> sent the certificate for the origin it wants to push for prior to pushing
> content, and violation of that is a *connection* error.  That doubly
> seems excessive, and I’ll change that in a PR shortly.)
>

---

From: Tom Bergan <[email-masked]>
Date: Tue, 14 Apr 2020 15:53:00 -0700

> unreasonable as a response.  Should this indicate that it’s a stream error

I think most people interpreted this to be a stream error on the promised
stream. Chrome already does this (although it uses REFUSED_STREAM_ERROR
instead of PROTOCOL_ERROR):
https://cs.chromium.org/chromium/src/net/spdy/spdy_session.cc?rcl=d9cde1be644011b978b48bf3eb8e35155b3cd800&l=2005

Firefox too (with the correct error code):
https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/Http2Session.cpp#2009