Re: JPEG-XL as Content-Encoding?

Willy Tarreau <w@1wt.eu> Thu, 20 August 2020 15:17 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 51E013A0B6F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 20 Aug 2020 08:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level:
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 znI7-8JuvJks for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 20 Aug 2020 08:17:19 -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 367413A0B75 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 20 Aug 2020 08:17:17 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1k8mGg-0003pt-Kr for ietf-http-wg-dist@listhub.w3.org; Thu, 20 Aug 2020 15:14:18 +0000
Resent-Date: Thu, 20 Aug 2020 15:14:18 +0000
Resent-Message-Id: <E1k8mGg-0003pt-Kr@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 <w@1wt.eu>) id 1k8mGe-0003p7-TA for ietf-http-wg@listhub.w3.org; Thu, 20 Aug 2020 15:14:16 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by titan.w3.org with esmtp (Exim 4.92) (envelope-from <w@1wt.eu>) id 1k8mGc-0003NZ-Q1 for ietf-http-wg@w3.org; Thu, 20 Aug 2020 15:14:16 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 07KFE1B4021700; Thu, 20 Aug 2020 17:14:01 +0200
Date: Thu, 20 Aug 2020 17:14:01 +0200
From: Willy Tarreau <w@1wt.eu>
To: Yoav Weiss <yoav@yoav.ws>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <20200820151401.GB21689@1wt.eu>
References: <CACj=BEjdwH1OtS=uQXsgPN3XVJvVEUeisjeF5_iro1vg0omqWQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CACj=BEjdwH1OtS=uQXsgPN3XVJvVEUeisjeF5_iro1vg0omqWQ@mail.gmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1k8mGc-0003NZ-Q1 cb91c2dfb5558940551b7318b53281f1
X-Original-To: ietf-http-wg@w3.org
Subject: Re: JPEG-XL as Content-Encoding?
Archived-At: <https://www.w3.org/mid/20200820151401.GB21689@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37941
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>

Hi Yoav,

On Thu, Aug 20, 2020 at 04:11:54PM +0200, Yoav Weiss wrote:
> Hey HTTPers!
> 
> I was reviewing an intent to add JPEG-XL as a content-encoding
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACZPrBjS75%3D%2B%3DSexFkJ7ewkBXDOF6FhkpwQYBeWn6sT57n1-_w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> for JPEG images, and thought I'd get some feedback from y'all regarding it.
> 
> The team behind JPEG-XL think that since it can be used to
> seamlessly transform JPEGs, it might be interesting to enable that
> transformation to happen at the HTTP layer and get ~20% smaller images
> *automagically*, as compression would be done by supporting web servers and
> image compression providers.
> 
> I'm slightly more skeptical about how automatic that would be, and find it
> somewhat strange to have image-specific content-encoding, while other image
> formats are served as separate mime types and negotiated with `Accept`.
> 
> So, a few questions:
> 
>    - Would it make sense to have an image specific content-encoding?
>    - Are web servers more likely to perform JPEG=>JPXL transformations if
>    JPXL is a content encoding, compared to browser support for it as an image
>    format?
>       - Note that those transformations are CPU heavy, so will need to be
>       cached, or done at "build" time.
>    - Same question for CDNs
>    - Finally for CDNs who already transform images - have you run into
>    compatibility issues coming from web content manipulating raw image bytes
>    directly, and failing to do that post-transformation?
> 
> I'd highly appreciate y'all's opinions!

Well, I don't know about this JPEG-XL but I'd argue that one very
important aspect of the content-coding is that it must absolutely
be possible to recover the original data by applying the inverse
transformation, as it's not supposed to transform the content but
only its representation. And intermediary might want to cache such
contents and use them to deliver the original image to clients not
compatible with this format, just as can be done with compressed
contents for example. I have no idea if this is the case here.
Otherwise I don't see how it could qualify as a content-encoding.

Just my two cents,
Willy