httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: Apache's new HTTP/1.1 stuff
Date Wed, 07 Aug 1996 00:30:47 GMT
On Tue, 6 Aug 1996, Roy T. Fielding wrote:

> > Narf. Well, actually, the spec doesn't say "the header MUST be ignored" or
> > "the header SHOULD be ignored", it just says "the header is ignored."
> > Which is wrong; in Apache it isn't :) There isn't a good way to do this,
> > given how Apache parses dates. Ugh.
> We can fix that.  When RobM and I worked on the original code for NCSA,
> I had a different method of comparing dates than was used in the final
> product -- I'll see if I can dig it up.

All right. I guess the question is: how do you determine an invalid date?
I suppose Apache could be a bit more stringent on how it checks dates -
later_than() (which is called when parsing If-Modified-Since and
Unless-Modified-Since headers) just kinda does a sscanf() on the header
without bothering to check the results - but in some sense, it's hard to
figure out the ivalidness of a date. I mean, Netscape 2.0 and later tack
on a ";length=whatever" to the end of every If-Modified-Since header they
send. Apache doesn't actually look at anything past the second, so it
ignores this, but it certainly does make it an invalid date, from one
standpoint. Yet I certainly don't want to never send a 304 to Netscape
Navigator, just because they do that.

> >> 2.  A TRACE method adds a Via: to the response headers, even
> >>     though the origin server isn't a gateway or proxy [14.44]
> > 
> > I see nothing in section 14.44 that says that the "the intermediate
> > protocols and recipeint...between the origin server and the client" must
> > be exclusive of the two.
> Ummm, "between" is exclusive.  In any case, that was what I intended.

All right then, I'll remove the code.

> > Yeah, yeah, yeah. I suppose this might be simple, but I'm really waiting
> > for Koen, et al to finish their new conneg stuff before redoing
> > mod_negotiation.
> Don't wait, dictate!  Koen's draft is going to take a while to scrape
> off the kruft he added, mostly because he still doesn't understand the
> concept of HTTP conneg.  That is really turning into a nightmare -- it has
> cost me more time arguing about it and twice fixing the changes to the
> spec than it would have cost to just write it myself.

Ergh. I think I agree. When reading Koen's drafts (both of 'em), I note
that the first half seems very well thought out and implemented, but the
second half (from about when he first brings in the idea of "feature
negotiation") gets progressivly murkier and murkier. But I like a lot of
the ideas he brings up in terms of transparent negotiation.


> Oooh, that should be optional in the spec -- I'll have to double-check that.
> All of conneg is supposed to be optional.

That's what I thought.


> Keep in mind that, for all intents and purposes, Apache will be the *real*
> specification of HTTP/1.1 since it will probably be the only complete and
> source-code-available implementation (at least until W3C or NCSA complete
> the Jigsaw version).  I would like to stick to the spec wherever possible,
> but make it easy for people to "localize" those strings.

Yeah, okay.


> No it does not -- it says applications should avoid using them when they
> are not necessary.  Apache never uses them when they are not necessary.
> Removing them is always wrong because it changes the type.  We don't
> actually suggest including ;qs=N somewhere, do we?

No. People have suggested it a couple times, because it does actually make
MultiViews work the way you'd think it would, but it isn't recommended (or
even desired) practice.

-- Alexei Kosut <>            The Apache HTTP Server

View raw message