HTTP2 push after serving content

0
votes

Is it possible to push content to the client after the requested content has already been served?

This Wikipedia article explains the sequence of frames as follows:

  1. Server receives HEADERS frame asking for index.html in stream 3...
  2. Server sends a PUSH_PROMISE for styles.css and a PUSH_PROMISE for script.js, again in stream 3...
  3. Server sends a HEADERS frame in stream 3 for responding to the request for index.html.
  4. Server sends DATA frame(s) with the contents of index.html, still in stream 3.
  5. Server sends HEADERS frame for the response to styles.css in stream 4
  6. Server sends HEADERS frame for the response to script.js in stream 6.
  7. Server sends DATA frames for the contents of styles.css and script.js, using their respective stream numbers.

I was wondering if, for example, I could keep open stream 3 and after I sent the DATA frame(s) for index.html and afterwards send PUSH_PROMISE frames.

Thanks for any responses :)

1
http2

1 Answers

1
votes

Is it possible to push content to the client after the requested content has already been served?

I believe the answer is 'no', based on 6.6. PUSH_PROMISE in RFC 7540. Here's the relevant quote (emphasis mine):

PUSH_PROMISE frames MUST only be sent on a peer-initiated stream that is in either the "open" or "half-closed (remote)" state. The stream identifier of a PUSH_PROMISE frame indicates the stream it is associated with. If the stream identifier field specifies the value 0x0, a recipient MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR.

Back to your question:

I was wondering if, for example, I could keep open stream 3 and after I sent the DATA frame(s) for index.html and afterwards send PUSH_PROMISE frames.

Here's something that I believe you could do, along those lines: you could send all DATA frames for stream 3 but withhold the END_STREAM flag thus keeping the (which means that the client would still be waiting for content). Then send the PUSH_PROMISE, then send an empty (zero length) DATA frame with END_STREAM set on stream 3. I can't think of a scenario where that would be useful, however.