Re: [quicwg/base-drafts] Import most H2 references (#3407)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> -requests MUST conform to the requirements in Section 8.2 of {{!HTTP2}}.
+{{frame-push-promise}}) on the request stream which generated the push. This
+allows the server push to be associated with a client request.
+
+Not all requests can be pushed.  A server MAY push requests which have the
+following properties:
+
+- cacheable (see Section 4.2.3 of [RFC7231])
+- safe (see Section 4.2.1 of [RFC7231])
+- does not include a request body
+
+Clients SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame
+carrying a request which is not cacheable, is not known to be safe, or that
+indicates the presence of a request body.  If the pushed response arrives on a
+push stream, this MAY be treated as a stream error of type
+H3_STREAM_CREATION_ERROR.

Requests can be cacheable, but have answers which turn out not to be cacheable.  The distinction we settled on for H2 was that you can only promise cacheable requests, but the response need not be cacheable.

Yes, all of this is an error.  The question is whether:
- it needs to be a stream error on the response that contains the push
- it can be detected at the right layer for that to happen

My reasoning is primarily that, if you need to decompress and examine the headers to determine whether something is in error, an immediate stream error is not the right response to mandate.  Instead, you mark the push as invalid -- cancel it, and reject the push stream if it purports to arrive.

Really, this is a case of the push being malformed, and the idea is to define a response to malformed pushes that's commensurate with malformed responses -- don't use it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3407#discussion_r384102031