Re: JPEG-XL as Content-Encoding?

Dmitri Tikhonov <dtikhonov@litespeedtech.com> Thu, 20 August 2020 18:33 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 F103B3A127E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 20 Aug 2020 11:33:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.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 LvLUzAqx_jfm for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 20 Aug 2020 11:33:24 -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 B2A183A127C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 20 Aug 2020 11:33:24 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1k8pKk-00063w-Po for ietf-http-wg-dist@listhub.w3.org; Thu, 20 Aug 2020 18:30:43 +0000
Resent-Date: Thu, 20 Aug 2020 18:30:42 +0000
Resent-Message-Id: <E1k8pKk-00063w-Po@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 <dtikhonov@litespeedtech.com>) id 1k8pKg-00062J-2g for ietf-http-wg@listhub.w3.org; Thu, 20 Aug 2020 18:30:39 +0000
Received: from mail-qt1-x833.google.com ([2607:f8b0:4864:20::833]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <dtikhonov@litespeedtech.com>) id 1k8pKe-0000Xx-2M for ietf-http-wg@w3.org; Thu, 20 Aug 2020 18:30:37 +0000
Received: by mail-qt1-x833.google.com with SMTP id f19so1924052qtp.2 for <ietf-http-wg@w3.org>; Thu, 20 Aug 2020 11:30:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=aumclCFAumU9AuEWSclyUeQmyCvCkKt7HUUNOy65NRU=; b=LchZZLQOqSfZn1Wta7myN4eEqiquJq8f1DMFRNreHDG1f+xtU9k5hzZrjnkzXaYLc1 kmihrh05dpla7h9z/rCEB0RNBMTFcd3MTldSKVNo+m+jTsOYOV/9fl9DErgVqkJbgc/q DANEYZ7hp9ESeN5R6L3m8AXoCnR4CcDQPVcG1rF2OhR1RuRNXfSuY2fICU1/Hqs/GNSq me41KGgHDyJCuOQ0IH0lEHehIHIJtHpAr4pzE31LIyzHFOqTRbLDaGzdhican3ug2cmG k3WyAYUXKcO5CkUSPzfJh3kwtqq/8EXf2efi9Lnfm7fSjf0OZAjPOdVrFIrio645rUAI zpng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=aumclCFAumU9AuEWSclyUeQmyCvCkKt7HUUNOy65NRU=; b=RJ4Re178ciwZXGL44VtmlgItl6839inlywO3JekrVEoUYfCNhtkbAr8Bk826hpzFGR +VtqXuI0L3XjbpbsvGI/QNFHQtXz15LCJu7iZs+hOHSLosWa0PRL1WEJVKgZ88MWMsJO l/y6xwkQAWmEZ9xMb1sdDfqnwLOLm9luw8sfVuZwZ9jECgIz7HzL8jqiphaHI/XaihyX JAfdmMUKuNwTVblmZx9dEqjLMoz7OieYQDzmP0KhP+9tQpvL9Q1XCr5N/kKuEobYdDNm qI8GpOdlciSvBDHZmHCgRdHDywIvr6YwiZiMr7EIis8r2t9B8Xihbt0Uc0sAwXdn9IX4 Xs2w==
X-Gm-Message-State: AOAM530evD7Xx5EkHqaKrOzWFGD8Gsc2Aj6g3IN8nQjA7oYm6rrr6vQv 2X6W5uxRVNZj9THSHHRPptNVkuBw0viCDw==
X-Google-Smtp-Source: ABdhPJwM5x4FDs1xQhXkLEHVornEY2dBf93EI2BeHtFSoFuEX0Pue7icfzHWL0A25Ql2rA+OoAOIYw==
X-Received: by 2002:ac8:7188:: with SMTP id w8mr3908440qto.223.1597948224690; Thu, 20 Aug 2020 11:30:24 -0700 (PDT)
Received: from lubuntu (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id w12sm2746455qkj.116.2020.08.20.11.30.23 for <ietf-http-wg@w3.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Aug 2020 11:30:24 -0700 (PDT)
Date: Thu, 20 Aug 2020 14:30:09 -0400
From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
To: ietf-http-wg@w3.org
Message-ID: <20200820183008.GA8086@lubuntu>
Mail-Followup-To: ietf-http-wg@w3.org
References: <CACj=BEjdwH1OtS=uQXsgPN3XVJvVEUeisjeF5_iro1vg0omqWQ@mail.gmail.com> <20200820151401.GB21689@1wt.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20200820151401.GB21689@1wt.eu>
User-Agent: Mutt/1.10.1 (2018-07-13)
Received-SPF: pass client-ip=2607:f8b0:4864:20::833; envelope-from=dtikhonov@litespeedtech.com; helo=mail-qt1-x833.google.com
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 1k8pKe-0000Xx-2M 2d9e97a4c638ed67bf1a058d76e5ec7b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: JPEG-XL as Content-Encoding?
Archived-At: <https://www.w3.org/mid/20200820183008.GA8086@lubuntu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37942
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>

Hello Yoav, Willy:

> On Thu, Aug 20, 2020 at 04:11:54PM +0200, Yoav Weiss wrote:
> > 
> > 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`.

I agree that this would be strange.

> >    - 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.

The transformation cost can be amortized over time by using a file
cache in the web server.

On Thu, Aug 20, 2020 at 05:14:01PM +0200, Willy Tarreau wrote:
> 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 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.

  - Dmitri.