httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@liege.ICS.UCI.EDU>
Subject Re: Apache's new HTTP/1.1 stuff
Date Tue, 06 Aug 1996 21:39:34 GMT
Thanks for testing things Paul -- keep it up.

Alexei wrote:
> On Mon, 5 Aug 1996, Paul Sutton wrote:
> 
>> 1.  If If-Unmodified-Since contains an invalid date, the request
>>     should be treated as having no If-Unmodified-Since header [14.28].
>>     Apache returns a 412 (Precondition Failed) response.
> 
> 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.

>> 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.

>> 3.  If Accept: is present but the server can find no acceptable
>>     variant, it SHOULD return 406 (not acceptable) [14.1]. Apache
>>     returns 404 (Not found)
> 
> 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.

>> 4.  Apache has not charset facility, so ignores Accept-Charset: (it
>>     SHOULD find an acceptable representation, else return 406) [14.2]
> 
> Yes.

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

>> 6.  All of 3,4 and 5 depend on mod_negotiation being compiled in
>>     and turned on. If it is not, Apache will _ignore_ Accept: and
>>     Accept-*: headers, and thus fail to implement the SHOULD requirements
>>     from [14.1] thru [14.4].
> 
> We say "You should not compile these out" in Configuration. Our should
> cancels out the spec's should. 

I agree.

>> 7.  Response code 503 has text "out of resources" but the spec uses
>>     "Service unavailable" (this only a comment text, but it would be
>>     nice to match exactly the spec since this message can be seen
>>     by users on errors). Also Apache doesn't list several new
>>     codes (eg 415, 505).
> 
> True. The spec just define's 'em, it doesn't say we have to send 'em. And
> several of our comment texts don't match the spec. That's okay, IMHO. I've
> seen SMTP implementations that have absolutely hilarious comment texts
> on their numeric codes... maybe we should, too. :)

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.

>> 8.  Requests containing invalid Host: (e.g. Host: doesnt-exist) are
>>     accepted [14.23]
> 
> Hmm? That's a valid Host: header. It's not a valid hostname, but the spec
> doesn't indicate behavior upon receiving an invalid hostname. So we just
> ignore it.

And that is the correct behavior -- it was the only reasonable course
of action given the bogus hosts received in Brian's earlier survey.

>> 9.  Content-Types: of (say) text/html;qs=0.6 can confuse browsers.
>>     [3.7] says that servers "should" (lowercase) remove parameters
>>     that aren't required by the mime type. qs isn't a mime parameter
>>     for text/html [rfc1866] so "should" be removed.

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?

>> 10. Requires FORHTTP11 to be defined (should this be the default?)
> 
> Note, though, that SERVER_PROTOCOL is "HTTP/1.0". If you define FORHTTP11,
> it can cause problems with real HTTP/1.1 clients. Roy has tried to
> convince me otherwise, but it hasn't worked. When (if?) the HTTP/1.1 is
> approved by the IESG, I plan to change the protocol to HTTP/1.1 and remove
> the defines (and what's between the #else and the #endif).

I still see no reason for the defines, though I now understand some of
the places where you change behavior based on whether the request was
in 1.0 or 1.1.  I'll submit patches when I get a chance to test the
features, but I'm busy as hell right now.  We'll include in Apache 1.2
whichever works best with clients (past and future).

.....Roy

Mime
View raw message