Re: HTTP/2 and non-authoritative pushes

On Tue, Apr 14, 2020 at 12:42 PM Mike Bishop <mbishop@evequefou.be> 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 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.)
>