> I’m also generally having an ick reaction to the idea of a response including metadata that is nothing to do with the resource but is intended to negotiate the client’s behaviour in future requests. This seems like something that should happen prior to the request, like the way we upgrade to H2, for example. Shoving negotiation into TLS handshake is neither simple, easy, nor makes it any more understandable to developers. Not to mention it would be a layer and functional mismatch: we're not negotiation connection-wide properties, we're defining caching policies against a specific resource or origin, which is precisely what HTTP req-resp negotiation is for. > This concern would be mitigated by doing this opt in via origin policy, so I wonder if that could offer a better solution. Origin Policy doesn't directly address any of this. It still relies on header-based delivery mechanism — which is what we're defining here — and optionally moves delivery of such headers into an origin wide policy file. As such, you still need to define all the headers we're talking about here. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/206#issuecomment-340207465
Received on Saturday, 28 October 2017 17:36:43 UTC