Re: JPEG-XL as Content-Encoding?

1. If the encoding is backward compatible for old clients then it does
not need a separate Content-Encoding i.e. it's not like gzipped text can't
be read.
2. Browsers can't even support concatenated gzip and xz compression ( lz4
and zst doesn't make sense). I wondered how quickly they integrated Brotli.
3. Intermediate proxies (i.e. Cloudlfare) can check file metadata/magic and
they don't really need for a separate mime type. But some simpler like
Nninx may need it to determine the processor. Basically mime types are
needed just to determine if file is text or binary, download or show it,
and basic type (e.g. image/video/archive)
4. I'm a regular developer and I saw that even png, ico mime type often is
added to filters and configs: e.g. upload file, compression filters like
Ziplet etc. On my current project favicon.ico is always auto compressed to
gzip. WebP files are still not widely supported and you can't even upload
screenshots.
IMHO if we can avoid a separate mime and content-encoding that will
simplify life for almost all except of intermediate proxies


On Fri, 21 Aug 2020 at 00:54, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> --------
> Dmitri Tikhonov writes:
>
> > I subscribe here as well.  In my mind, the way to switch the response
> > from JPEG to JPXL is as follows:
> >
> >     Request:
> >
> >         GET /image.jpg
> >         Accept: image/jpxl
> >
> >     Response:
> >
> >         OK...
> >         Content-Type: image/jpxl
> >         Vary: accept
> >
> > If 'Accept' does not specify image/jpxl, the server returns the original
> > JPEG image.  Note that there is still the white lie of the image's .jpg
> > extension, but this lie is smaller than the much more elaborate dance
> > with the Content-Encoding.
>
> Agreed.
>
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>

-- 
Sergey Ponomarev <https://linkedin.com/in/stokito>, skype:stokito