Discussion raised the issue of what can and cannot be cached when resources are pushed.
From an HTTP/1.1 caching perspective, a pushed resource could be considered analogous to responses where Content-Location != effective request URI. We need to consider how these resources can be cached.
This also needs to carefully cover the effect on Vary header fields. The current draft specified that request header fields for pushed resources are inherited from the request that triggered the push. A cache would have to pull details from that original request.
Since this opens Pandora's box, we might also consider cacheability of other resources when Content-Location and Cache-Control header fields are present.
The text was updated successfully, but these errors were encountered:
Discussion raised the issue of what can and cannot be cached when resources are pushed.
From an HTTP/1.1 caching perspective, a pushed resource could be considered analogous to responses where Content-Location != effective request URI. We need to consider how these resources can be cached.
This also needs to carefully cover the effect on Vary header fields. The current draft specified that request header fields for pushed resources are inherited from the request that triggered the push. A cache would have to pull details from that original request.
Since this opens Pandora's box, we might also consider cacheability of other resources when Content-Location and Cache-Control header fields are present.
The text was updated successfully, but these errors were encountered: