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

>The Fetch API has no explicit API to correlate streams based on id so correlation in the application layer has to be done on resource URL.

I presume the fetch API would just define a property on the response object (tailingMetadata or whatever). The implementation would do the correlation based on the stream IDs. The URL would just be to match a name provided by the fetch specification so that you know it is providing trailingMetadata and not some other piece of information.

> Given that PUSH_PROMISE stipulates that the response of the pushed stream is cacheable (8.2.1)

it doesn't say that afaict. what are you referring to?  8.2 talks specifically about how non cachable responses can be given to the application (the application in this case is the fetch() implementation) but not placed in a generic cache. I think that's fine for this use case.

> if you have two active streaming POST responses from the same URL you would have a hard time determining which push-promise entry in the cache was associated with which active request and would likely be forced to implement some higher-level scheme again.

The appropriate request is obvious to the fetch() implementation (not the user of the fetch api) because it has visibility into the stream ids



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