Subject: Is HTTP/1.0 still relevant?

From: Eric J Bowman <[email-masked]>
Date: Thu, 03 Sep 2020 22:13:13 -0700

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.

-Eric

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 4 Sep 2020 07:40:51 +0200

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

---

From: Eric J Bowman <[email-masked]>
Date: Fri, 04 Sep 2020 00:09:24 -0700

---- On Thu, 03 Sep 2020 22:40:51 -0700 Willy Tarreau <mailto:[email-masked]> wrote ---- 

On Thu, Sep 03, 2020 at 10:13:13PM -0700, Eric J Bowman wrote:

Hey Willy! Long time no chat. :) I try to code for all intermediaries and

clients, not just browsers, but at this point in time I'm also trying to

eliminate edge cases from my code, because I want to hold it all in my head.

I both appreciate and hate your answer! I didn't realize that the sorts of

testing scripts you mention are still looking for HTTP/1.0 compat. I'm

coding a development server, but I want it to handle significant real-world

traffic all the same. I don't care about meeting any test criteria but my

own, I suppose, when you get down to it. But I am an old dog trying to learn

new tricks!

> blocks. In short, Connection defaults to close instead of keep-alive...

Exactly! My code's a lot cleaner and even removes a comment, if I default

to HTTP/1.1 for the Connection header. I'm trying to avoid "just add[ing] a

few" lines of code. It's 2020. I want to hold my webserver code in my head.

I don't want to eplain back-compat with HTTP/1.0 anymore, let alone pollute

my code with it, unless it's really still necessary, which I'm trying to

ascertain.

Every httpd I've ever coded or configured, has bent over backwards to avoid

T-E chunked or 1xx responses, and requires the Host header. But hey, if this

was 2005, I'd be 95% done with my webserver code, not like, 33% tops atm...

> the content-length header.

Hmmm... yeah. Development server. Strict is fine. I'll be making HTTP/1.1

my baseline and not worrying about 1.0, but thanks for explaining to me how

that can go wrong. For this project, I don't think I care. If I did care,

thanks for pointing out that it isn't all that difficult to support 1.0.

Your two cents is always worth a nickel. ;)

-Eric

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 4 Sep 2020 09:16:36 +0200

On Fri, Sep 04, 2020 at 12:09:24AM -0700, Eric J Bowman wrote:
(...)
> thanks for pointing out that it isn't all that difficult to support 1.0.

Then at least make sure to reject 1.0 as 505 not supported and not to just
handle it like 1.1, otherwise your users will really face bugs. The typical
thing a developer does is to use telnet or netcat to send a local dirty
request "by hand" when curl for whatever reason is not suitable (e.g. you
want to see when exactly the server rejects your input), and seeing the
connection hung after a response to an 1.0 request is confusing.

Cheers,
Willy

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 4 Sep 2020 09:17:32 +0200

> Am 04.09.2020 um 09:09 schrieb Eric J Bowman <[email-masked]>:
> 
> ---- On Thu, 03 Sep 2020 22:40:51 -0700 Willy Tarreau <[email-masked]> wrote ---- 
> >
> > Hi,
> >

Many existing OCSP clients in servers (*cough*), use HTTP/1.0 to staple certificates. I have no data from the IoT devices of the world, but I would suspect many of them will do as well.

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

Cheers, Stefan

---

From: Matthew Kerwin <[email-masked]>
Date: Fri, 4 Sep 2020 17:18:40 +1000

On Fri, Sep 4, 2020 at 3:19 PM Eric J Bowman <[email-masked]> wrote:

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

In BOFH land we have monitors that still use HTTP/0.9 requests for
heartbeat status checks. If the response isn't exactly the two bytes 0x55
0x50 ("UP") it yanks the server from the load-balancing pool.

So, something to consider.

Cheers
-- 
  Matthew Kerwin
  https://matthew.kerwin.net.au/

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 4 Sep 2020 09:23:10 +0200 (CEST)

On Fri, 4 Sep 2020, Stefan Eissing wrote:

> Many existing OCSP clients in servers (*cough*), use HTTP/1.0 to staple 
> certificates. I have no data from the IoT devices of the world, but I would 
> suspect many of them will do as well.

On "IoT devices", meaning things that are smaller than what can comfortably 
run Linux, "HTTP(S) clients" are often the RTOS vendor's 100 lines of C code 
without error checks full of dirty assumptions which can only be considered 
HTTP/1.0 at best...

Luckily, such devices often use a specific subset of servers for particular 
purposes so most of those won't randomly go using servers "in the wild".

-- 

  / daniel.haxx.se

---

From: Sergey Ponomarev <[email-masked]>
Date: Fri, 4 Sep 2020 10:40:26 +0300

JFYI: current version BysyBox httpd web server for embedded devices uses
HTTP/1.0. If you are using Ubuntu you can run it locally `busybox httpd -h
/var/www -p 8080`.
But in the next release it will be upgraded to HTTP/1.1.
Chrome doesn't send cache validation headers like If-Modified-Since and
If-None-Match if previously it received the page with old HTTP/1.0.

If you are just implementing a web server then you can only implement
HTTP/1.1. It was released in 1999 and all clients support it. Even if a
client receives a header that it doesn't know it will ignore it.

-- 
Sergey Ponomarev <https://linkedin.com/in/stokito>, skype:stokito

---

From: Eric J Bowman <[email-masked]>
Date: Fri, 04 Sep 2020 01:09:02 -0700

---- On Fri, 04 Sep 2020 00:40:26 -0700 Sergey Ponomarev <mailto:[email-masked]> wrote ---- 

> JFYI: current version BysyBox httpd web server for embedded devices uses HTTP/1.0.

> If you are using Ubuntu you can run it locally `busybox httpd -h /var/www -p 8080`.

My dev environment is actually Bodhi Linux, I put my httpd controller at /var/www/

:8080 though, lol... But, thanks, I'm not familiar with that httpd, so of course I'll

give it a look.

> If you are just implementing a web server then you can only implement HTTP/1.1.

> It was released in 1999 and all clients support it. Even if a client receives a

> header that it doesn't know it will ignore it.

I don't understand "only". I get the gist of how this all works, I have been a Web

developer since we called it Mosaic. Will the HTTP police bust me if I implement

HTTP/0.9 or HTTP/2? ;)

-Eric

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 4 Sep 2020 10:21:36 +0200

On Fri, Sep 04, 2020 at 09:17:32AM +0200, Stefan Eissing wrote:
> 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

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

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 4 Sep 2020 11:02:24 +0200 (CEST)

On Fri, 4 Sep 2020, Willy Tarreau wrote:

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

Good point. It is actually a fairly common pattern in curl land:

  - user wants to know the size of the transfer upfront but gets chunked
    reposne
  - adds option to go HTTP/1.0
  - server then gives Content-Length: in response
  - user remains using HTTP/1.0 for that use case

-- 

  / daniel.haxx.se

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 4 Sep 2020 11:05:27 +0200

On Fri, Sep 04, 2020 at 11:02:24AM +0200, Daniel Stenberg wrote:
> > will *not* parse chunks and will instead consume data after the empty
> > header till the end of the connection.
> 

They're lucky because it could perfectly just deliver the data and close!

>  - user remains using HTTP/1.0 for that use case

Sure, most of the time, once a solution appears to work, it stays forever.

Willy

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 4 Sep 2020 11:08:24 +0200 (CEST)

> They're lucky because it could perfectly just deliver the data and close!

Yes absolutely. And it somewhat puzzling to a client-oriented mind like mine 
that there are servers that opt to go chunked even though they apparently have 
the size ...

-- 

  / daniel.haxx.se

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 4 Sep 2020 11:13:20 +0200

On Fri, Sep 04, 2020 at 11:08:24AM +0200, Daniel Stenberg wrote:
> that there are servers that opt to go chunked even though they apparently
> have the size ...

Maybe they actually go the hard way and buffer everything just to
count... I've already seen such horrors a long time ago.

Willy

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 4 Sep 2020 11:28:47 +0200

I mean, to be honest, the Internet worked best at the time of HTTP/1.0. ;)

Stefan

> Am 04.09.2020 um 11:13 schrieb Willy Tarreau <[email-masked]>:
>

---

From: Eric J Bowman <[email-masked]>
Date: Fri, 04 Sep 2020 03:13:52 -0700

---- On Fri, 04 Sep 2020 02:28:47 -0700 Stefan Eissing <mailto:[email-masked]> wrote ---- 

If I were President I'd sign an executive order banning cookies. ;)

-Eric

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 5 Sep 2020 22:37:35 +1200

On 4/09/20 7:18 pm, Matthew Kerwin wrote:
> 
> 
> On Fri, Sep 4, 2020 at 3:19 PM 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.
> 
>     -Eric
> 
> 
> heartbeat status checks. If the response isn't exactly the two bytes
> 0x55 0x50 ("UP") it yanks the server from the load-balancing pool.
> 

Oh dear. I was about to ask if anyone had seen it recently.

Are you able to mention software/application names I can reference in
reply to the requests to remove the HTTP/0.9 support from Squid?

Cheers
Amos