httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: HTTP/1.0 to HTTP/1.1 irony
Date Sun, 26 Jan 1997 23:23:25 GMT
On Sun, 26 Jan 1997, Jason S. Clary wrote:

> Has anyone else noticed the irony of a supposed minor protocol
> change that requires a draft spec that is 3 times longer than
> its predecessor?

It's minor in the sense that HTTP/1.1 is really only slightly
different than HTTP/1.0 in function and form. HTTP/1.1 just adds a
whole bunch of new options. Actually, most of the HTTP/1.1 draft deals
with caching. The actual Transport (the third letter) part isn't that

> I just printed both HTTP/1.0 and HTTP/1.1 along with the other
> related RFC's and HTTP/1.1 is HUGE...  1 1/2 inch thick BOOK...
> HTTP/1.0 was less than a half inch.

Well, the two RFCs are for different purposes. The HTTP/1.1 RFC
defines a standard. Although it wasn't approved as such, the HTTP/1.0
RFC was supposed to be a BCP (Best Current Practice) RFC (it ended up
as an Informational one, though) - in other words, it doesn't define
the whole HTTP/1.0 spec (before the http-wg decided to scrap HTTP/1.0
as an Internet standard and do HTTP/1.1, the 1.0 spec was a lot
longer), just the parts of it that are in common use.

> BTW, I've been reading this thing pretty closely.. what is
> this need for threading that everyone is talking about?
> It seems like it could all be done the same way its done now
> with the possible exception of requiring output processing
> even on CGIs (chunking and encoding and whatnot) which
> would best be accomplished through threading but could
> be done just as easily with fork() and a select loop on
> the output of the forked process.

Umm... It *is* done now. Apache, except for the proxy module, is (as
far as we know), completely unconditionally compliant with
HTTP/1.1. It's HTTP/2.0 that will require threading.

Alexei Kosut <>      The Apache HTTP Server

View raw message