Re: Is HTTP/1.0 still relevant?

Willy Tarreau <w@1wt.eu> Fri, 04 September 2020 08:24 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 9EF943A0B90 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 4 Sep 2020 01:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Level:
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 f2nClEDNwuRp for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 4 Sep 2020 01:24:46 -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 151613A0B8E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 4 Sep 2020 01:24:45 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1kE6yq-0002zk-RP for ietf-http-wg-dist@listhub.w3.org; Fri, 04 Sep 2020 08:21:57 +0000
Resent-Date: Fri, 04 Sep 2020 08:21:56 +0000
Resent-Message-Id: <E1kE6yq-0002zk-RP@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 1kE6yp-0002yt-0t for ietf-http-wg@listhub.w3.org; Fri, 04 Sep 2020 08:21:55 +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 1kE6yn-0001NQ-6n for ietf-http-wg@w3.org; Fri, 04 Sep 2020 08:21:54 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 0848LawO002957; Fri, 4 Sep 2020 10:21:36 +0200
Date: Fri, 4 Sep 2020 10:21:36 +0200
From: Willy Tarreau <w@1wt.eu>
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: Eric J Bowman <mellowmutt@zoho.com>, Ietf Http Wg <ietf-http-wg@w3.org>
Message-ID: <20200904082136.GC2905@1wt.eu>
References: <174578870d7.1265f983c12789.7350275676057542310@zoho.com> <20200904054051.GA2905@1wt.eu> <17457f2cfaa.b1c12efb13715.7081201094742751967@zoho.com> <13FF9481-ADFB-4006-A237-9CA795507C5B@greenbytes.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <13FF9481-ADFB-4006-A237-9CA795507C5B@greenbytes.de>
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 1kE6yn-0001NQ-6n b1fee160114c01a177adf4375cc6e82e
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Is HTTP/1.0 still relevant?
Archived-At: <https://www.w3.org/mid/20200904082136.GC2905@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38008
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>

On Fri, Sep 04, 2020 at 09:17:32AM +0200, Stefan Eissing wrote:
> Many existing OCSP clients in servers (*cough*), use HTTP/1.0 to staple
> certificates.

Ah I didn't know, that's interesting! Now that you're speaking of this,
I'm pretty sure we have somewhere and old HTTP client made to retrieve
config files that's also 1.0 only. Often clients that speak 1.0 are
those which want to advertise that they will *not* parse chunks and
will instead consume data after the empty header till the end of the
connection.

> I have no data from the IoT devices of the world, but I would
> suspect many of them will do as well.

In the IoT world it tends to be awful, with code trying to imitate HTTP/1.1
using strstr() and consorts to find the relevant minimal parts :-/ Quite
frankly it would be cleaner to stick to 1.0 sometimes!

> Be happy when you can get away without supporting HTTP/0.9. ;)

We disabled it by default 5 years ago in haproxy and didn't get any single
complaint (except from the usual developer complaining that "GET /" on
telnet now returns 400). So far so good :-)

Willy