WICG / compression-dictionary-transport

Other
92 stars 8 forks source link

Content-Type (MIME) of Dictionary #44

Closed Jxck closed 3 months ago

Jxck commented 11 months ago

I found that there are no definition of MIME type for dictionary itself in demo.

image

application/compression-dictionary maybe ?

pmeenan commented 11 months ago

Correct. Since any resource can be used as a dictionary, it spans different mime types. For the case where previous versions of a file are used as dictionaries for the next version the mime type will be whatever type the file is (js, css, wasm, even binary formats). For the case of a stand-alone dictionary, a single dictionary could be used against multiple content types. We could probably define a new type specifically for stand-alone dictionaries but there's no reason for a hard requirement.

annevk commented 9 months ago

I looked into this a tiny bit. The reason this isn't an issue is due to the use-as-dictionary response header.

pmeenan commented 3 months ago

Closing this out since dictionaries themselves do not have an inherent mime type.

annevk commented 3 months ago

I think if standalone dictionaries have their own format we should define a MIME type and probably enforce it too. Generally not defining MIME types had led to a number of difficulties down the road.

pmeenan commented 3 months ago

Thanks. I went ahead and moved it over to the HTTP Working group issue tracker then to register a MIME type (and recommend a file extension). https://github.com/httpwg/http-extensions/issues/2755