Server Push and Status Codes

[Mark Nottingham <[e-mail]>]

In principle, any HTTP status code can be pushed in a response. Success (2xx), redirection (300, 301, 302, 303, 307, 308) and eror (4xx and 5xx) status codes all have the same caching semantics (as long as you pay attention to rules like those for heuristics), described in RFC7234.

This implies that if they are pushed to the client, any of these status codes should behave as if the client had requested them previously and stored the response. For example, a 403 (Forbidden) can be pushed and stored just as a 200 (OK) -- even if this would be of very limited use.

That said, a few things to consider:

* 304 (Not Modified) has special interaction with caches and validation; I'll cover that separately.

* Other 3xx Redirection codes indicate, when pushed, that if the client were to make that request, it will be redirected. That does not mean that the `Location` header's URL should be followed immediately; it is only upon an actual request from the client that it should be acted upon. In other words, 3xx redirects SHOULD be cached just like anything else (i.e., if the headers allow it), and used if the client makes a request to the URL.

* 1xx Informational codes don't make much sense as a Push payload, because the headers they convey are lost in most implementations (to be subsumed by the headers in the final response). For example, the headers on a 100 (Continue) response are a no-op; effectively, it's a one-bit "go ahead" signal. Since HTTP/2 already has protocol-level signalling mechanisms, it's probably best to say that 1xx responses SHOULD NOT be sent in Server Push, and MUST be ignored when received.

* 401 (Unauthorized) has the side effect of prompting the user for their credentials. Again, this does not mean that the User Agent ought to do so when receiving a pushed 401; rather, this could be seen as a mechanism to avoid the round trip that would otherwise be required -- just as in other intended uses of Server Push. Presumably, the PUSH_PROMISE for such a request would omit the `Authentication` header field.

* 407 (Proxy Authenticate) is probably best not to push, since it's confusing authority of the network vs. the origin. Clients SHOULD ignore such pushes.

* Many other 4xx and 5xx status codes don't have any practical use in Server Push; e.g., 405 (Method Not Allowed), 408 (Request Timeout), 411 (Length Required) and 414 (URI Too Long) are all reactions to problems with the request. Since the server has sent that request, their use is somewhat self-defeating; however, this does not mean that a client encountering them should generate an error, or fail to use the response. At the very least, if the response is available in devtools, debugging will be easier; additionally, someone might find a creative, appropriate use for them some day.

Does this approach make sense?

--
Mark Nottingham   https://www.mnot.net/