Does the `accept` or `sec-fetch-dest` header matter?

[styfle]

In previous discussions, we decided that accept header didn't matter since any content is accepted.

And we also decided that sec-fetch-dest should be empty.

Though I recently noticed that the PR for the similar proposal (import text) is including a custom sec-fetch-dest. So that has me second guessing the decision to make sec-fetch-dest empty. Perhaps it should have a new value for bytes 🤔

[styfle]

Any thoughts here? @eemeli @bakkot @ctcpip @guybedford @annevk @nicolo-ribaudo @ljharb @domenic

[eemeli]

See this comment and other discussion in tc39/proposal-import-text#9 for some of the concerns that are addressed by allowing the server to determine the request's destination.

[bakkot]

Strictly speaking I believe tc39/proposal-import-text#9 is addressed as long as Sec-Fetch-Dest is present and has a value which is not "script". Empty works just as well.

[annevk]

I think having a value here is probably good in case someone has a need to differentiate on it. In practice I would expect servers to treat text, bytes, and the empty string about the same.

[ljharb]

It seems to me that we would actively want to prevent someone from differentiating it?

[nicolo-ribaudo]

If type: "text" and type: "bytes" had the same destination, then they would also have the same Accept header and we could de-duplicate the requests.

If for text imports we want a custom destination, then it makes sense to give this proposal its own too.

[styfle]

I don't have strong opinions one way or the other. Though I think we should follow the same convention that proposal-import-text uses.

@eemeli What was the decision for import text? Is it going to use a unique sec-fetch-dest? I'm also curious if it will have an accept header since that is another way the server could differentiate import text vs import bytes.

[eemeli]

What was the decision for import text? Is it going to use a unique sec-fetch-dest?

Yes, text.

I'm also curious if it will have an accept header since that is another way the server could differentiate import text vs import bytes.

It'll default to Accept: text/plain,*/*;q=0.5, but that can be customized by each request.

[styfle]

Thanks all. I created a PR:

• fix: add requirement of Accept: */* and Sec-Fetch-Dest: bytes #32