httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Not-a-bug: .asis handler isn't driven
Date Mon, 01 Oct 2001 14:38:47 GMT
It isn't a problem, 1.3 mime/negotation is subtely broken, so of course
this works in 1.3.

OK ... let's start from page one.

Two files in a directory:

index.html.en    1590 bytes    1632 bytes

if the user's Accept-Language header is simply en, and they request
index.html, they will get the .en variant.  Accept-Language of fr
will return the french variant.  Accept-Language of anything else
returns Not Acceptable, and no Accept-Language will return the
index.html.en variant if the LanguagePriority is set with en and fr
both present and occuring in that order.

Now, Admin copies to index.html.temp.  Starts editing,
deletes two paragraphs...

index.html.temp  1039 bytes

User requests index.html with AcceptLanguage en or fr.  They aught
to get the right file.  User has another Accept-Language.  They MAY
get index.html.temp, because the others failed, and .temp inserts no
no language identification to reject.  They provide no Accept-Language,
and they _will_ get index.html.temp, based on size alone.

The sequence of files in the directory becomes significant.  The last
file in the readdir will either win or kill multiviews parsing if it's 
an unrecognized extension.  Filesize becomes significant, absurdly so.
The old behavior is bogus, Users who received bogus autoindex listings 
often had an unrecognized file at the _end_ of the readdir, mostly 
because they updated their index.html.** entries for the docroot from 
a new version of Apache, but they didn't update the list of languages 
in httpd.conf.

I've identified the patches to apply, and they should resolve this bug 
in 1.3 as well.  Let's get back to 'usual' behavior.  We also accepted
the handler in 1.3 multiviews and carried this into 2.0.  I noticed 
this when I added the Add{Input|Output}Filter processing.

The asis-handler .asis doesn't contribute to the negotiation.  If the 
user doesn't ask for .asis, it shouldn't be served.  This would become
much more pronounced when the user starts associating Filters with
file extensions.

Asking multiviews to select by handler (or to serve unrecognized 
extensions) is as bogus as similar IIS behaviors.  It isn't predictable.
Why would you expect .asis to be 'magically' served when the user doesn't
ask for the extension, while you expect .bak to 'magically' not be

If it's an element of the Accept-* negotiation, it needs to be
multiview-matched.  If it isn't, it has no business in there.

If you disagree with the above sentence, let's narrow the argument to
that statement.


View raw message