Re: HTTP/2 and non-authoritative pushes

[Tom Bergan <[e-mail]>]

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

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

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