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 Mon, 05 Aug 1996 16:24:33 GMT
On Mon, 5 Aug 1996, Paul Sutton wrote:

> Hello, I've been looking at the HTTP/1.1 spec for a future apache week
> article, using Apache 1.2 as my test server.  I've noticed a few things
> which I think are not compliant (or at least, are not 'unconditionally'
> compliant).  Since I'm not 100% familiar with HTTP/1.1 I don't know if
> these are valid, but here they are anyway:

Observations are always valid; it's the intepretations of those
observations that aren't valid. :P

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

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

> 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

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


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

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

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

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


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

-- Alexei Kosut <>            The Apache HTTP Server

View raw message