Re: Is HTTP/1.0 still relevant?

---- On Thu, 03 Sep 2020 22:40:51 -0700 Willy Tarreau <mailto:w@1wt.eu> 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!



>

> 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