Re: Is HTTP/1.0 still relevant?

Willy Tarreau <w@1wt.eu> Fri, 04 September 2020 05:43 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 BB7043A0544 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 3 Sep 2020 22:43:36 -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 M1LAIuaiXCXO for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 3 Sep 2020 22:43:35 -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 029D53A0598 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 3 Sep 2020 22:43:34 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1kE4TH-00014D-C7 for ietf-http-wg-dist@listhub.w3.org; Fri, 04 Sep 2020 05:41:11 +0000
Resent-Date: Fri, 04 Sep 2020 05:41:11 +0000
Resent-Message-Id: <E1kE4TH-00014D-C7@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 1kE4TG-00013R-7y for ietf-http-wg@listhub.w3.org; Fri, 04 Sep 2020 05:41:10 +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 1kE4TA-0005rc-VD for ietf-http-wg@w3.org; Fri, 04 Sep 2020 05:41:10 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 0845epOw002913; Fri, 4 Sep 2020 07:40:51 +0200
Date: Fri, 4 Sep 2020 07:40:51 +0200
From: Willy Tarreau <w@1wt.eu>
To: Eric J Bowman <mellowmutt@zoho.com>
Cc: Ietf Http Wg <ietf-http-wg@w3.org>
Message-ID: <20200904054051.GA2905@1wt.eu>
References: <174578870d7.1265f983c12789.7350275676057542310@zoho.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <174578870d7.1265f983c12789.7350275676057542310@zoho.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 1kE4TA-0005rc-VD b470c107697bb9015a96835a2847b549
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Is HTTP/1.0 still relevant?
Archived-At: <https://www.w3.org/mid/20200904054051.GA2905@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38000
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,

On Thu, Sep 03, 2020 at 10:13:13PM -0700, Eric J Bowman wrote:
> Hi, I'm greenfield-coding a webserver, and wondering if I can just do away
> with back-compat with HTTP/1.0. My concern is it's still alive and kicking on
> intermediaries. Is there any empirical data on this? Opinions also
> appreciated.

It really depends what your target is. If you want to support browsers
and nothing else, it's probably fine to simply fail on it. If you're
expecting that applications built on top of your web server are compatible
with various perf testing tools, monitoring scripts, availability tests,
dirty in-house search engines, or just succeed in some compliance tests,
it's probably better to still support it.

In addition I'd suggest that once you've implemented HTTP/1.1, you'll
note that implementing HTTP/1.0 requires no effort as it's only a subset
of HTTP/1.1, so you'll just have to add a few "if" around some code
blocks. In short, Connection defaults to close instead of keep-alive,
neither chunked transfer-encoding nor 1xx responses are expected to be
supported, and Host is optional. Thus not supporting 1.0 would make your
1.1 implementation look fairly suspicious about its ability to adapt to
a client or server's 1.1 capabilities.

The real difficulty with 1.0 is that most of the time such requests come
from very low-quality clients (mostly scripts) that do not even look at
the content-length header. What could probably be reasonable if you want
to keep the effort very low is to always disable keep-alive in 1.0 so that
you don't care how dirty the client implementation can be. But quite frankly
the effort is very low. Looking through the whole haproxy code base, I'm
only spotting 9 places where we take care of this version difference, both
sides included, that's really cheap.

Just my two cents,
Willy