Re: Is HTTP/1.0 still relevant?

[Stefan Eissing <[e-mail]>]

> Am 04.09.2020 um 09:09 schrieb Eric J Bowman <[e-mail]>:
> 
> ---- On Thu, 03 Sep 2020 22:40:51 -0700 Willy Tarreau <[e-mail]> wrote ---- 
> >
> > 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.
> >
> 
> 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!

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

> >
> > 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...
> >
> 
> 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.
> 
> >
> > 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.
> >
> 
> 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 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.
> >
> 
> 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.
> 
> >
> > Just my two cents,
> > Willy
> >
> 
> Your two cents is always worth a nickel. ;)
> 
> -Eric
> 
>