Re: [fetch] Access to the HTTP trailer (#34)

>  rereading the spec, there is also this gotcha:
>    It is not possible to push a response to a request that includes a request body. - 8.2.1

the request (body) in question here is not the associated stream that started the fetch (stream 5 in our example) - it is talking about the request for the pushed stream (6 in the example). Every transaction has a request and response, for a pushed stream the request headers are in the push promise (in this case something like GET /.well-known... always GET even if the fetch was a POST) and the response headers are in a normal headers frame (bearing stream id 6). So the RFC requirement says the push promise request headers cannot have a request body (indeed it has no way to express one) - but the associated stream (the fetch) certainly can.

> Would the cache then have to take stream ID into account when creating the cache-key for ./well->known/...? Also, how would I access it as a developer -- would the UA automatically look it up and make it available as a property on the Response object? 

>From an HTTP level, I would define the pushed metadata response as uncachable and then proivde a definition for caching fetch() that is bigger than just mapping to the transaction that started the fetch. 8.2 specifically says you can have an uncachable pushed response with a lifetime that matches the associated stream "Pushed responses are considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive is present ([RFC7234], Section 5.2.2)) while the stream identified by the promised stream ID is still open." - so you can use it to satisfy the metadata aims of a particular fetch() but you don't need to worry about it ending up polluting the namespace of the general cache.






---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/34#issuecomment-123476887