Re: [w3c/ServiceWorker] Should synthetic responses be validated? (#1571)

> In the case where they don't match it becomes a network error in HTTP/1

This is key. Some headers relate to the transport, others relate to web platform features. Things that relate to the transport no longer apply when they're coming from the HTTP cache or a synthetic response, and it feels like `content-length` is part of that.

Same goes for things like chunked encoding, and caching headers.

Here's a practical example of why we shouldn't validate content length:

```js
addEventListener('fetch', (event) => {
  event.respondWith((async function() {
    const response = await fetch(event.request);
    // Let's pretend the response isn't opaque 
    const body = await response.blob();
    return new Response(body, { headers: response.headers });
  })());
});
```

In this case I'm creating a new synthetic response with the same headers as the original response. However, this will also copy things like `Content-Length` and `Content-Encoding`. The original `Content-Length` may be `100123` due to brotli compression, but the synthetic response's body may be many megabytes.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1571#issuecomment-797536619