Re: JPEG-XL as Content-Encoding?

Sergey Ponomarev <stokito@gmail.com> Thu, 20 August 2020 23:01 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2813A148A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 20 Aug 2020 16:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.996
X-Spam-Level:
X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9ryeyh74tbp for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 20 Aug 2020 16:01:23 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1803A148D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 20 Aug 2020 16:01:22 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1k8tVx-0006dY-F0 for ietf-http-wg-dist@listhub.w3.org; Thu, 20 Aug 2020 22:58:33 +0000
Resent-Date: Thu, 20 Aug 2020 22:58:33 +0000
Resent-Message-Id: <E1k8tVx-0006dY-F0@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <stokito@gmail.com>) id 1k8tVt-0006cm-9o for ietf-http-wg@listhub.w3.org; Thu, 20 Aug 2020 22:58:29 +0000
Received: from mail-oi1-x22f.google.com ([2607:f8b0:4864:20::22f]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <stokito@gmail.com>) id 1k8tVr-00087C-6q for ietf-http-wg@w3.org; Thu, 20 Aug 2020 22:58:29 +0000
Received: by mail-oi1-x22f.google.com with SMTP id j7so3336058oij.9 for <ietf-http-wg@w3.org>; Thu, 20 Aug 2020 15:58:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3pzyduhrRlZvw064XNg4771dGjOFJ4I/Lgm4ZEBN7SQ=; b=gtejs6qOo1sMS9Rsj8Cci7i2JwraucNV7KAcYMTz88tENhw3G6pxnCbA+fJWDiv3Dh IAorRHVvhqHm6UpXQmuiBMBZql4HcG3n3DZFthbMgmcHaofpVAQA+ubT1oGS8m52z/YY wzPdRSxTXKApf1Md1j/uVK7jwqNfF8gdhxF2/x2k8FUVdrtiS6XN4r0a6ypIFDVnksvC LcQlxhktPQmTwnc2OF4iX6zaXgCHsER/LJj1VZ8PQmrTX5/PVdky3Yrpzf3n5fdTGxf4 TACYu54gdAWYlaNflD9+482WHCQtAc7QTfl+nL6ne2hIhadc4putbudXlw5oq09Ar2Bs s30Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3pzyduhrRlZvw064XNg4771dGjOFJ4I/Lgm4ZEBN7SQ=; b=TugTbt6ut2CSrUt92iZjIZkNijx6c35vFBBjSN6RTOwdKBvJ5ko0BP+0aZVaM6CXda 1RNAyltkPbZgpzvlWr/bYC2mrI7IHEPItEnC+4OWd5X5R+NrxeYb1M0AVPFJvOY3xw3i ahTorGQGz4pN2v6npRCONHn2jGP142X+fb5FLJFvcXZ/6YAyOOYgmIFyvTC5oblbqhsz 2XxkzMVjASUIGE4b0IOstdWD4B+6qT/p0V4p/roahIqS77J8vWYtWweiWCtuPh1UzUAj IS9UA4cA7fj5+VqfsaJrp2tw93mh6HHp5y7p7nuL62vOXWZkUobD6GjBjxPvHLVwkDCT WWkw==
X-Gm-Message-State: AOAM532H5WdXZOonN7aqHEuR88fEoxqxkB9+2ZXIgyA9FUU3MU6FKBzC Ru+dLlRVrSrI4m+nE3UI0QIvghCzRxDh5iASMDfNn+bKFmDvaA==
X-Google-Smtp-Source: ABdhPJwDcIPtWv4uwe5jJRvRLKNWYoJCC9S4aojNnX4tJ7Va0CTecV6IRh6CbSiXc9u0IEzg7SDDICNNhjE83y/LDAc=
X-Received: by 2002:aca:240b:: with SMTP id n11mr126619oic.47.1597964286298; Thu, 20 Aug 2020 15:58:06 -0700 (PDT)
MIME-Version: 1.0
References: <CACj=BEjdwH1OtS=uQXsgPN3XVJvVEUeisjeF5_iro1vg0omqWQ@mail.gmail.com> <20200820151401.GB21689@1wt.eu> <20200820183008.GA8086@lubuntu> <18159.1597960275@critter.freebsd.dk>
In-Reply-To: <18159.1597960275@critter.freebsd.dk>
From: Sergey Ponomarev <stokito@gmail.com>
Date: Fri, 21 Aug 2020 01:57:28 +0300
Message-ID: <CADR0UcWkxb4ZtMgjqDeAv=m6G3ks2P75L-5pvt-ctz8WyJF29g@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Dmitri Tikhonov <dtikhonov@litespeedtech.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000a6128f05ad570d12"
Received-SPF: pass client-ip=2607:f8b0:4864:20::22f; envelope-from=stokito@gmail.com; helo=mail-oi1-x22f.google.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1k8tVr-00087C-6q c57d2bb6a463d00b34160bb6cd573e42
X-Original-To: ietf-http-wg@w3.org
Subject: Re: JPEG-XL as Content-Encoding?
Archived-At: <https://www.w3.org/mid/CADR0UcWkxb4ZtMgjqDeAv=m6G3ks2P75L-5pvt-ctz8WyJF29g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37946
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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