Mailing List Archive

On Fri, 18 Aug 1995, Brian Behlendorf wrote:

> 1) spend a few more weeks squishing bugs and adding a few small cosmetic
> features here and there (like scoreboard.pl, which I haven't gotten to
> work yet), and *make sure it implements all of the HTTP/1.0 "BCP" draft*,
> and call that Apache 1.0. Is there anything not in Apache now that
> should be in HTTP/1.0 servers, even as a non-required option?

Hmm. We don't send the Allow: header, I don't believe, anywhere. But
glancing over the spec quickly, that's the only thing I see that we don't
do.

Well.. there is something that, while it's not really in the spec
(Appendix A), we've implemnted incorrectly: We should rename
http/send-as-is to message/http.

Also... we're not a proxy server. Does that count?

> 2) When the HTTP 1.1 draft is released, start implementing items from it
> (like digest auth) and revising current items that need to be revised
> (like content negotiation). Start releasing those new modules and
> bugfixes as Apache 1.0.x, with Apache 1.1 as the "stable" implementation
> of HTTP/1.1 as it moves to last call.

Sounds good. When do we change the version number in the status line from
HTTP/1.0 to HTTP/1.1? At Apache 1.0.1, at 1.1, or at some point in
between? I'd recommend the third. When we're first mimimally complient
with HTTP 1.1, we should change it.

> 3) Repeat for HTTP/1.2 and Apache 1.2

Sounds good.

--/ Alexei Kosut <akosut@nueva.pvt.k12.ca.us> /--------/ Lefler on IRC
----------------------------/ <http://www.nueva.pvt.k12.ca.us/~akosut/>
The viewpoints expressed above are entirely false, and in no way
represent Alexei Kosut nor any other person or entity. /--------------

On Fri, 18 Aug 1995, Alexei Kosut wrote:
> On Fri, 18 Aug 1995, Brian Behlendorf wrote:
>
> > 1) spend a few more weeks squishing bugs and adding a few small cosmetic
> > features here and there (like scoreboard.pl, which I haven't gotten to
> > work yet), and *make sure it implements all of the HTTP/1.0 "BCP" draft*,
> > and call that Apache 1.0. Is there anything not in Apache now that
> > should be in HTTP/1.0 servers, even as a non-required option?
>
> Hmm. We don't send the Allow: header, I don't believe, anywhere. But
> glancing over the spec quickly, that's the only thing I see that we don't
> do.
>
> Well.. there is something that, while it's not really in the spec
> (Appendix A), we've implemnted incorrectly: We should rename
> http/send-as-is to message/http.

Excellent suggestion.

> Also... we're not a proxy server. Does that count?

No, only if we were selling ourselves as one. Of course, if someone
wants to implement a proxy module, I would certainly vote to include it
in /contrib.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

>Hmm. We don't send the Allow: header, I don't believe, anywhere. But
>glancing over the spec quickly, that's the only thing I see that we don't
>do.

Yep, probably right -- what I left in 1.0 is pretty much NCSA httpd 1.3.

>Well.. there is something that, while it's not really in the spec
>(Appendix A), we've implemnted incorrectly: We should rename
>http/send-as-is to message/http.

Actually, no. message/http is (or will be) a real MIME type, which
means you wouldn't want to do things like change

Status: 302

into a 302 response code. Note also that message/http could be a request.

>Also... we're not a proxy server. Does that count?

Nope, you don't have to implement the entire protocol. In fact, an
HTTP/0.9 server is still compliant.

>Sounds good. When do we change the version number in the status line from
>HTTP/1.0 to HTTP/1.1? At Apache 1.0.1, at 1.1, or at some point in
>between? I'd recommend the third. When we're first mimimally complient
>with HTTP 1.1, we should change it.

I recommend not changing it until you need some feature implemented
that requires all of HTTP/1.1's requirements (i.e., content negotiation,
when done right, will also require the cache notification via URI: ...).

In other words, we can do anything we want in 1.0, but saying 1.1 implies
that we must do certain things exactly as specified (which is a little
difficult when the specification is incomplete).

......Roy

On Sat, 19 Aug 1995, Roy Fielding wrote:

> Actually, no. message/http is (or will be) a real MIME type, which
> means you wouldn't want to do things like change
>
> Status: 302
>
> into a 302 response code. Note also that message/http could be a request.

Hmmm. Okay. It just seemed to make sense using message/http. Guess not.

> I recommend not changing it until you need some feature implemented
> that requires all of HTTP/1.1's requirements (i.e., content negotiation,
> when done right, will also require the cache notification via URI: ...).

Right. Which brings up a question for the people who coded Apache (rst
mainly): I haven't looked, but is there a way for modules to easily
determine what version of HTTP was used to send the request message?
Looking over draft-ietf-http-v10-spec-01.txt, I see several places where
we'll want to respond differently to HTTP/1.0 responses than to 1.1
and later - with HTTP/1.2, this becomes even more pronounced, I believe.

> In other words, we can do anything we want in 1.0, but saying 1.1 implies
> that we must do certain things exactly as specified (which is a little
> difficult when the specification is incomplete).

Good point. Although, once we do do things exactly as specified, we
should call ourselves 1.1. Right?

--/ Alexei Kosut <akosut@nueva.pvt.k12.ca.us> /--------/ Lefler on IRC
----------------------------/ <http://www.nueva.pvt.k12.ca.us/~akosut/>
The viewpoints expressed above are entirely false, and in no way
represent Alexei Kosut nor any other person or entity. /--------------

Date: Fri, 18 Aug 1995 15:58:05 -0700 (PDT)
From: Brian Behlendorf <brian@organic.com>

2) When the HTTP 1.1 draft is released, start implementing items from it
(like digest auth) and revising current items that need to be revised
(like content negotiation). Start releasing those new modules and
bugfixes as Apache 1.0.x, with Apache 1.1 as the "stable" implementation
of HTTP/1.1 as it moves to last call.

3) Repeat for HTTP/1.2 and Apache 1.2

Thoughts?

Hmmm... while protocol conformance is obviously a good thing, I'm not
sure I see the virtue in tying our own version numbering to the HTTP
WG's drafts --- it is not obvious that the two groups will work at the
same pace, and most of the features we've already marked down as
desirable for a 1.1 (if the fixed-up 0.8 becomes 1.0) don't have much
to do with the protocol per se (better logging, a smooth way to add
new includes directives, better config package, etc.)...

rst

Date: Sat, 19 Aug 1995 15:26:15 -0700 (PDT)
From: Alexei Kosut <akosut@nueva.pvt.k12.ca.us>

Right. Which brings up a question for the people who coded Apache (rst
mainly): I haven't looked, but is there a way for modules to easily
determine what version of HTTP was used to send the request message?
Looking over draft-ietf-http-v10-spec-01.txt, I see several places where
we'll want to respond differently to HTTP/1.0 responses than to 1.1
and later - with HTTP/1.2, this becomes even more pronounced, I believe.

The "protocol" element of request_rec structures should be the
information required --- this gets set to "HTTP/0.9" for an old-format
request, to whatever the client sent for HTTP/1.x format requests, and
to "INCLUDED" for the internally-generated requests which are used to
handle stuff like server-side includes (you could follow r->main
pointers out to the original request if you wanted to know the actual
protocol).

Right now, the CGI module is the only thing that makes any use of this
information, but it's there if anyone wants it.

Good point. Although, once we do do things exactly as specified, we
should call ourselves 1.1. Right?

In terms of what we send in response headers, I assume, you mean. If
so, then yes, it certainly seems that way to me...

rst

From: rst@ai.mit.edu (Robert S. Thau)
Date: Sat, 19 Aug 95 19:03:10 EDT

The "protocol" element of request_rec structures should be the
information required --- this gets set to "HTTP/0.9" for an old-format
request, to whatever the client sent for HTTP/1.x format requests, and
to "INCLUDED" for the internally-generated requests which are used to
handle stuff like server-side includes (you could follow r->main
pointers out to the original request if you wanted to know the actual
protocol).

Right now, the CGI module is the only thing that makes any use of this
information, but it's there if anyone wants it.

Note added in proof: of course, use of this sort of info in modules
probably ought to be minimized to the extent possible, because it will
lead to proliferation of code which has to be adapted to further
changes of the protocol. To the extent that stuff stays in the core,
and ideally to within http_protocol.c itself, it's that much easier to
adapt the server to protocol changes.

(I tried in my original spadework to try to keep protocol-dependant
information to http_protocol.c, not always as well as I should have
--- for instance, mod_cgi.c uses CONTENT_LENGTH to count off the bytes
it should read via read_client_block(). IMHO, it would have been
better to have read_client_block() keep count itself, so that when we
transition to chunked transfer encoding (which indicates end of data
in a different way), we just have to change the protocol code, and not
the CGI code --- this is a cleanup I'm thinking about for subsequent
releases... ).

rst

On Sun, 20 Aug 1995, Robert S. Thau wrote:

> Note added in proof: of course, use of this sort of info in modules
> probably ought to be minimized to the extent possible, because it will
> lead to proliferation of code which has to be adapted to further
> changes of the protocol. To the extent that stuff stays in the core,
> and ideally to within http_protocol.c itself, it's that much easier to
> adapt the server to protocol changes.

Well, let me give an example of the sort of things I was thinking about:

Right now, the content-negotation code prevents caching of documents by
witholding the Last-modified header. This is the only way to ensure that
all current proxies don't cache the document, although it doesn't let local
client caches work either, which is bad. Now, from my understanding of
recent discussions on the http-wg mailing list, HTTP 1.1 will have a
response header along the lines of "Pragma: private", which will ensure
that proxies will not cache the document, but local caches can.

Now, this is perfect for content negotation, but we'd only want it to
happen with requests labeled HTTP/1.1 and later, as they are the old ones
we can be sure will support the header. For HTTP/1.0 requests, we'll
still want to simply not send Last-modified.

Hmm... wait. Never mind. I just checked the code, and apparently the
neccessary change would in fact be in http_protocol.c, and
mod_negotiation.c would remain the same. Oops. Guess you did a nicer job
of programming this thing than I had figured. :)

Still, the concept still holds. Doesn't it?

Alexei Kosut

--/ Alexei Kosut <akosut@nueva.pvt.k12.ca.us> /--------/ Lefler on IRC
----------------------------/ <http://www.nueva.pvt.k12.ca.us/~akosut/>
The viewpoints expressed above are entirely false, and in no way
represent Alexei Kosut nor any other person or entity. /--------------

Date: Sun, 20 Aug 1995 23:24:53 -0700 (PDT)
From: Alexei Kosut <akosut@nueva.pvt.k12.ca.us>

Hmm... wait. Never mind. I just checked the code, and apparently the
neccessary change would in fact be in http_protocol.c, and
mod_negotiation.c would remain the same. Oops. Guess you did a nicer job
of programming this thing than I had figured. :)

Still, the concept still holds. Doesn't it?

If "the concept" is that protocol information should be available in
case some module needs to be aware of the protocol to function
correctly... well, yes, that's why it's there. I still think that
where such cases arise, it's generally symptomatic of a design error,
either in the module itself or in the server core, but unfortunately,
nobody's perfect...

rst