Re: Is HTTP/1.0 still relevant?

Willy Tarreau <> Fri, 04 September 2020 05:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB7043A0544 for <>; Thu, 3 Sep 2020 22:43:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.65
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M1LAIuaiXCXO for <>; Thu, 3 Sep 2020 22:43:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 029D53A0598 for <>; Thu, 3 Sep 2020 22:43:34 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1kE4TH-00014D-C7 for; Fri, 04 Sep 2020 05:41:11 +0000
Resent-Date: Fri, 04 Sep 2020 05:41:11 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kE4TG-00013R-7y for; Fri, 04 Sep 2020 05:41:10 +0000
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1kE4TA-0005rc-VD for; 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 <>
To: Eric J Bowman <>
Cc: Ietf Http Wg <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=;;
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: 1kE4TA-0005rc-VD b470c107697bb9015a96835a2847b549
Subject: Re: Is HTTP/1.0 still relevant?
Archived-At: <>
X-Mailing-List: <> archive/latest/38000
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


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,