You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@covalent.net> on 2001/10/01 04:01:59 UTC
Re: .asis handler isn't driven
Greg, this isn't an error, and the early "Success" was a catastrophic
failure for many cases.
If a user of 1.3/earlier 2.0 copied index.html to index.html.bak, and
added a new paragraph to index.html, then queried index.html ...
index.html.bak was returned, since the file was _smaller_.
Any extension that A) was not requested, or B) is not negotatied
is not eligable to be served.
[There is a weakness. We need to evaluate the exception list by
component, right now we simply strcmp. There is a note in status to
that effect. E.g. requesting index.bak -should- match index.html.bak,
but it wouldn't. Although we can test -in-order-, we simply need to
check that each extension that didn't match was an extension of the
requested filename.]
Bill
----- Original Message -----
From: "Greg Ames" <gr...@remulak.net>
To: <de...@httpd.apache.org>
Sent: Friday, September 28, 2001 4:25 PM
Subject: .asis handler isn't driven
> www.apache.org was recently changed so that www.apache.org/search.html
> became search.html.asis .
> That document contains a 301 Moved Permanantly response, referring to
> http://search.apache.org/ .
>
> It works fine with 2.0.24, but fails with the current HEAD with:
>
> [Thu Sep 27 13:49:14 2001] [error] [client 32.97.136.236] Negotiation:
> discovered file(s) matching request: /www/www.apache.org/search.html
> (None could be negotiated).
>
> daedalus's config file contains:
>
> AddHandler send-as-is asis
>
> The log entry is created by read_types_multi() in mod_negotiation,
> called by its type checker phase. Shortly before this log entry, there
> is a loop which attempts to match prefixes of directory entries against
> "exceptions" discovered by mod_mime. The closest we ever come to a
> match in this loop is comparing "search.html" from the dir to
> "search.asis" from the exceptions list. There is some code that notices
> that sub_req->handler and ->content_type are non-null, but that isn't
> enough to make it happy. We eventually return HTTP_NOT_FOUND from
> read_types_multi(), so the asis handler never gets a shot the request.
>
> I suspect mod_mime more than mod_negotiation, because the changes to the
> latter in the type checker seem pretty innocent since 2.0.24. But I
> don't know how this interface is supposed to work.
>
> After read_types_multi() runs a subrequest for search.html.asis,
> sub_req->handler == "send-as-is" and sub_req->content_type ==
> "text/html". I would think that's about all the type checking phase
> needs, and read_types_multi() should say
> "OK, mod_mime knows the full scoop for this variant, so I should be
> happy with it too."
>
> Greg
>
Re: .asis handler isn't driven
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Rodent of Unusual Size" <Ke...@Golux.Com>
Sent: Wednesday, October 03, 2001 8:54 AM
> "William A. Rowe, Jr." wrote:
> >
> > [There is a weakness. We need to evaluate the exception
> > list by component, right now we simply strcmp. There is
> > a note in status to that effect. E.g. requesting index.bak
> > -should- match index.html.bak
>
> Um, no, I definitely think not. I think the portion of
> the filename that's specified in the URL should be
> considered opaque, and that we can only negociate using
> the bits that are tailed on the file names but not the
> URL.
There are two issues, the list of exceptions (base name and the
elements that are _unrecognized_ by mime negotation) and the actual
file name accepted. I meant the first issue when I posted this.
The first issue I patched last night for 2.0, I'm sure FirstBill will
pick up that patch and backport to 1.3. It goes like this... the user
requests index.html.old and we have an index.html.old.en file to match.
But the exception list contains index and old, since html is a mime
type and en is a language. We compared index.old to index.html.old
(the exceptions to the request) and would fail! That was badness. The
patch ignores the request's .html segment, and simply assures that both
index and .old are part of the _requested_ name before it's willing to
allow that file to be served. No more serving .bak files without being
asked, but it behaves more similarly to the old 1.3 behavior now.
The second issue is allowing the request index.old to serve index.html.old,
which would work with Francis's patch (abiet with a small change)...
I'll answer that in a second post, with the right subject.
Re: .asis handler isn't driven
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"William A. Rowe, Jr." wrote:
>
> [There is a weakness. We need to evaluate the exception
> list by component, right now we simply strcmp. There is
> a note in status to that effect. E.g. requesting index.bak
> -should- match index.html.bak
Um, no, I definitely think not. I think the portion of
the filename that's specified in the URL should be
considered opaque, and that we can only negociate using
the bits that are tailed on the file names but not the
URL.
That is, if the URI is index.bak, we can only negociate
amongst variants matching index.bak* -- NOT index.*.bak*.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"
Re: .asis handler isn't driven
Posted by Cliff Woolley <cl...@yahoo.com>.
On Tue, 2 Oct 2001, Greg Ames wrote:
> > index.html.cgi
> > index.html.ssi
>
> A lot of these just sound like configuration errors. I don't think we
> should write a lot of code to deal with them. If we serve an arbitrary
> file, fine; if we produce an error message, also fine, as long as our
> code kept simple.
++1. I was thinking the exact same thing yesterday.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: .asis handler isn't driven
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Bill Stoddard" <bi...@wstoddard.com>
Sent: Tuesday, October 02, 2001 4:08 PM
> This is one of those 'light bulb comes on' posts.
>
> The mod_mime bug of not correctly handling unknown file name extensions essentially
> renders all the negotiable variants equivalent! mod_negotiation does the right thing and
> serves up the smallest of the equivalent variants!
Yes! The question before the list is --- is this goodness :-?
I argue no, that two files, a script and a static file, we need to
somehow express the static file is better than script.
Roy's point is good, IMHO, we can do so with mime-types. But 'handler'
isn't negotiated, so that is a bad factor to 'weigh' (without some
Prefer directive as was suggested.)
Bill
Re: .asis handler isn't driven
Posted by Bill Stoddard <bi...@wstoddard.com>.
This is one of those 'light bulb comes on' posts.
The mod_mime bug of not correctly handling unknown file name extensions essentially
renders all the negotiable variants equivalent! mod_negotiation does the right thing and
serves up the smallest of the equivalent variants!
Bill
> On Tue, Oct 02, 2001 at 11:02:46AM -0700, Justin Erenkrantz wrote:
> > On Tue, Oct 02, 2001 at 12:01:54PM -0500, William A. Rowe, Jr. wrote:
> > > IMHO, if we have unpredictable behavior due to directory -contents-,
> > > then mod_negotiation is broken.
>
> There was nothing unpredictable about it before.
>
> > +1 (me too).
> >
> > Although I have no clue what the proper solution to this, I'm kind
> > of sure that if we are choosing based off file size, that is wrong.
> > There is no correlation between file size and actual content size
> > (think of a php-file versus a static file). The only thing I could
> > think of is a preference directive like so:
>
> The original purpose of content negotiation was to select the highest
> quality and smallest transfer size image that a browser supports for
> an in-line image. Size does matter.
>
> > Prefer html shtml php jsp cgi
>
> We don't need another config directive. All of these used to be special
> mime types, but somebody decided it was better to define them as handlers.
> Well, all we have to do then is add them to the mime type table (or as
> a separate table) and score them higher in negotiation.
>
> ....Roy
>
Re: .asis handler isn't driven
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Roy T. Fielding" <fi...@ebuilt.com>
Sent: Tuesday, October 02, 2001 3:43 PM
> On Tue, Oct 02, 2001 at 11:02:46AM -0700, Justin Erenkrantz wrote:
>
> > Although I have no clue what the proper solution to this, I'm kind
> > of sure that if we are choosing based off file size, that is wrong.
> > There is no correlation between file size and actual content size
> > (think of a php-file versus a static file). The only thing I could
> > think of is a preference directive like so:
>
> The original purpose of content negotiation was to select the highest
> quality and smallest transfer size image that a browser supports for
> an in-line image. Size does matter.
Of course it does - but not in contrast to serving 6000 bytes of static
data against 1000 bytes of interpreted script.
> > Prefer html shtml php jsp cgi
>
> We don't need another config directive. All of these used to be special
> mime types, but somebody decided it was better to define them as handlers.
> Well, all we have to do then is add them to the mime type table (or as
> a separate table) and score them higher in negotiation.
++1 --- Mime configuration would be much more effective in solving this
entire class of 'problems', as I pointed out, even for the .asis issue.
We suggest by-mime-type in some places, and caution against it in others.
Which is it people? Do we 'endorse' by-mime-type, or by-handler.
I've always been partial to the former.
Re: .asis handler isn't driven
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Tue, Oct 02, 2001 at 11:02:46AM -0700, Justin Erenkrantz wrote:
> On Tue, Oct 02, 2001 at 12:01:54PM -0500, William A. Rowe, Jr. wrote:
> > IMHO, if we have unpredictable behavior due to directory -contents-,
> > then mod_negotiation is broken.
There was nothing unpredictable about it before.
> +1 (me too).
>
> Although I have no clue what the proper solution to this, I'm kind
> of sure that if we are choosing based off file size, that is wrong.
> There is no correlation between file size and actual content size
> (think of a php-file versus a static file). The only thing I could
> think of is a preference directive like so:
The original purpose of content negotiation was to select the highest
quality and smallest transfer size image that a browser supports for
an in-line image. Size does matter.
> Prefer html shtml php jsp cgi
We don't need another config directive. All of these used to be special
mime types, but somebody decided it was better to define them as handlers.
Well, all we have to do then is add them to the mime type table (or as
a separate table) and score them higher in negotiation.
....Roy
Re: .asis handler isn't driven
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Justin Erenkrantz" <je...@ebuilt.com>
Sent: Tuesday, October 02, 2001 1:02 PM
> On Tue, Oct 02, 2001 at 12:01:54PM -0500, William A. Rowe, Jr. wrote:
> > IMHO, if we have unpredictable behavior due to directory -contents-,
> > then mod_negotiation is broken.
>
> +1 (me too).
>
> Although I have no clue what the proper solution to this, I'm kind
> of sure that if we are choosing based off file size, that is wrong.
> There is no correlation between file size and actual content size
> (think of a php-file versus a static file). The only thing I could
> think of is a preference directive like so:
>
> Prefer html shtml php jsp cgi
This could be mapped by another integer, after the other variables
(language et al) and compared by index order (0 sorting first.)
Note that html wouldn't be in that list - it's a content type
(negotiated parameter) --- although it could be treated twice, to
carry additional weight in a dispute.
The others, php, jsp, cgi etc would be very appropriate in this list,
since they wouldn't toggle any other negotation parameters (unless they
are configured by mime-type rather than handler.)
> I'm not sure I absolutely like it, but I don't know how else we
> can achieve what we want. It sounds like it must explicit. I don't
> think there is anything we can or should do for 1.3, but for 2.0, I
> think we should come up with something that we agree is right.
>
> > In the words of many administrators, "It shouldn't be this hard to
> > understand."
>
> In the words of many developers, too. -- justin
:)
RE: .asis handler isn't driven
Posted by Joshua Slive <jo...@slive.ca>.
> -----Original Message-----
> From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
>
> Prefer html shtml php jsp cgi
>
> > In the words of many administrators, "It shouldn't be this hard to
> > understand."
>
> In the words of many developers, too. -- justin
>
Come on folks. Is this all really necessary?
In my years of reading apache newsgroups/mailing lists/bug databases, I
cannot recall a single person being confused by this issue. (The main
reason being that most people, very sensibly, don't use multiviews. Those
that do generally know what they are doing.)
If you have ties in the negotiation, that means someone screwed up. If you
don't like file size to break ties, why not just use an alphabetic sort on
the filename?
Joshua.
Re: .asis handler isn't driven
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Tue, Oct 02, 2001 at 12:01:54PM -0500, William A. Rowe, Jr. wrote:
> IMHO, if we have unpredictable behavior due to directory -contents-,
> then mod_negotiation is broken.
+1 (me too).
Although I have no clue what the proper solution to this, I'm kind
of sure that if we are choosing based off file size, that is wrong.
There is no correlation between file size and actual content size
(think of a php-file versus a static file). The only thing I could
think of is a preference directive like so:
Prefer html shtml php jsp cgi
I'm not sure I absolutely like it, but I don't know how else we
can achieve what we want. It sounds like it must explicit. I don't
think there is anything we can or should do for 1.3, but for 2.0, I
think we should come up with something that we agree is right.
> In the words of many administrators, "It shouldn't be this hard to
> understand."
In the words of many developers, too. -- justin
Re: .asis handler isn't driven
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"William A. Rowe, Jr." wrote:
>
> No. multiviews were created to allow the -client- to
> select one of many variants based on their preferences
> (gzip/no gzip, english or croatian, html or image.)
Not quite. As has been pointed out, 'negociation' is a bad
term for what goes on -- which is the server trying to
make an intelligent selection of a variant according to
the parameters supplied by the client. The client does
*no* selection, it just provides the parameters.
And to all the people saying 'size should never have been
a factor' I say 'BS'. If all of the variants are equally
acceptable according to the client's parameters, it makes
*perfect* sense to send the one that takes the least bandwidth.
The problem, of course, is that the definition of 'equally
acceptable' is moot. In this case, it is up to the Webmaster
to assign quality ratings.
> It shouldn't become a dumping ground for every flip-flop
> the administrator chooses to make.
Things change. The Web was only 'supposed' to interlink
text documents. Back when we were a bunch of Webmasters
only, we made changes that made our lives easier. Now
that most of the people here are *not* Webmasters, what's
our motivation for making changes? If it's anything to
do with usability, then it behooves us to pay attention
to ways to make things easier for users, and NOT to dictate
to them how or how not to run their sites.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"
Re: .asis handler isn't driven
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Joshua Slive" <jo...@slive.ca>
Sent: Tuesday, October 02, 2001 1:06 PM
> > From: William A. Rowe, Jr. [mailto:wrowe@covalent.net]
>
> > The directory CONTENTS cannot be construed as a config error.
> >
> > If we can agree on some scheme to handle examples, such as the above,
> > then I could begin to have some confidence. If we can't -clearly-
> > document the expected behavior (whatever we agree that is), then it
> > is too complex for reason. And if it's too complex to configure or
> > administer, I'm willing to propose we drop mod_negotation entirely.
> >
>
> Sure, it is confusing that adding a file to a directory can change the
> results for existing URLs. But really, that is the whole point of
> multiviews.
No. multiviews were created to allow the -client- to select one of many
variants based on their preferences (gzip/no gzip, english or croatian,
html or image.) It shouldn't become a dumping ground for every flip-flop
the administrator chooses to make.
> It should not be used in the general case, but if people ask
> for multiviews, they are explicitly asking for the url to depend on the
> directory contents. If an administrator turns on multiviews without
> informing web authors about the consequences, then he or she has made an
> error.
Oh come on ... you and I both know that getting server config info or
changes from the big mass-vhosting providers can be like pulling teeth.
> If that is not clear, then the documentation should be changed. (And
> I have no sympathy for people who try to use a complex feature like
> multiviews without reading the documentation.)
Nor I ... but let's assume they have limited information. It should at
least be predictable.
Bill
RE: .asis handler isn't driven
Posted by Joshua Slive <jo...@slive.ca>.
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@covalent.net]
> The directory CONTENTS cannot be construed as a config error.
>
> If we can agree on some scheme to handle examples, such as the above,
> then I could begin to have some confidence. If we can't -clearly-
> document the expected behavior (whatever we agree that is), then it
> is too complex for reason. And if it's too complex to configure or
> administer, I'm willing to propose we drop mod_negotation entirely.
>
Sure, it is confusing that adding a file to a directory can change the
results for existing URLs. But really, that is the whole point of
multiviews. It should not be used in the general case, but if people ask
for multiviews, they are explicitly asking for the url to depend on the
directory contents. If an administrator turns on multiviews without
informing web authors about the consequences, then he or she has made an
error. If that is not clear, then the documentation should be changed. (And
I have no sympathy for people who try to use a complex feature like
multiviews without reading the documentation.)
Joshua.
Re: .asis handler isn't driven
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Greg Ames" <gr...@remulak.net>
Sent: Tuesday, October 02, 2001 11:44 AM
> "William A. Rowe, Jr." wrote:
> >
> > Better yet...
> >
> > DirectoryIndex index.html
> >
> > index.html.cgi
> > index.html.ssi
> >
> > where cgi is set via AddHandler, ssi is set via AddFilter.
> >
> > That is a really good demonstration. Neither .cgi nor .ssi offers any
> > hint to mod_negotiation of what it aught to do.
> >
> > The smaller file wins, whether that makes a bit of sense, or not.
>
> A lot of these just sound like configuration errors. I don't think we
> should write a lot of code to deal with them. If we serve an arbitrary
> file, fine; if we produce an error message, also fine, as long as our
> code kept simple.
The directory CONTENTS cannot be construed as a config error.
Very often the admin (configurator) has nothing to do with the author
who is populating the directory.
IMHO, if we have unpredictable behavior due to directory -contents-,
then mod_negotiation is broken.
If we can agree on some scheme to handle examples, such as the above,
then I could begin to have some confidence. If we can't -clearly-
document the expected behavior (whatever we agree that is), then it
is too complex for reason. And if it's too complex to configure or
administer, I'm willing to propose we drop mod_negotation entirely.
In the words of many administrators, "It shouldn't be this hard to
understand."
Bill
Re: .asis handler isn't driven
Posted by Greg Ames <gr...@remulak.net>.
"William A. Rowe, Jr." wrote:
>
> Better yet...
>
> DirectoryIndex index.html
>
> index.html.cgi
> index.html.ssi
>
> where cgi is set via AddHandler, ssi is set via AddFilter.
>
> That is a really good demonstration. Neither .cgi nor .ssi offers any
> hint to mod_negotiation of what it aught to do.
>
> The smaller file wins, whether that makes a bit of sense, or not.
A lot of these just sound like configuration errors. I don't think we
should write a lot of code to deal with them. If we serve an arbitrary
file, fine; if we produce an error message, also fine, as long as our
code kept simple.
Greg
Re: .asis handler isn't driven
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "William A. Rowe, Jr." <wr...@covalent.net>
Sent: Monday, October 01, 2001 1:03 PM
> From: "Greg Ames" <gr...@remulak.net>
> Sent: Monday, October 01, 2001 11:59 AM
>
> > Actually, for the / situation, it looks like mod_dir will pick the first
> > match. daedalus has "DirectoryIndex index.html index.cgi" coded. It
> > runs a subrequest for index.html first; if that works, we redirect to
> > index.html and don't bother with index.cgi.
Better yet...
DirectoryIndex index.html
index.html.cgi
index.html.ssi
where cgi is set via AddHandler, ssi is set via AddFilter.
That is a really good demonstration. Neither .cgi nor .ssi offers any
hint to mod_negotiation of what it aught to do.
The smaller file wins, whether that makes a bit of sense, or not.
Bill
Re: .asis handler isn't driven
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Greg Ames" <gr...@remulak.net>
Sent: Monday, October 01, 2001 11:59 AM
> Greg Ames wrote:
> >
> > "William A. Rowe, Jr." wrote:
> >
> > > We still have no mechanism to 'quantify' the quality of one handler or
> > > filter over another. Funny that
> > >
> > > index.html 4000 bytes
> > > index.cgi 500 bytes
> > >
> > > will serve index.cgi, based on size, when the cpu impact of index.html is
> > > _significantly_ less expensive ;)
> > >
> >
> > I don't know what to say about this situation when the URI is "index" or
> > /. My gut says this is just ambiguous and is a user error. Picking one
> > based on size seems pretty arbitrary.
>
> Actually, for the / situation, it looks like mod_dir will pick the first
> match. daedalus has "DirectoryIndex index.html index.cgi" coded. It
> runs a subrequest for index.html first; if that works, we redirect to
> index.html and don't bother with index.cgi.
Picture this instead;
DirectoryIndex index
That better documents the inconsistancy.
Bill
Re: .asis handler isn't driven
Posted by Greg Ames <gr...@remulak.net>.
Greg Ames wrote:
>
> "William A. Rowe, Jr." wrote:
>
> > We still have no mechanism to 'quantify' the quality of one handler or
> > filter over another. Funny that
> >
> > index.html 4000 bytes
> > index.cgi 500 bytes
> >
> > will serve index.cgi, based on size, when the cpu impact of index.html is
> > _significantly_ less expensive ;)
> >
>
> I don't know what to say about this situation when the URI is "index" or
> /. My gut says this is just ambiguous and is a user error. Picking one
> based on size seems pretty arbitrary.
Actually, for the / situation, it looks like mod_dir will pick the first
match. daedalus has "DirectoryIndex index.html index.cgi" coded. It
runs a subrequest for index.html first; if that works, we redirect to
index.html and don't bother with index.cgi.
Greg
Re: .asis handler isn't driven
Posted by Greg Ames <gr...@remulak.net>.
"William A. Rowe, Jr." wrote:
>
> From: "Greg Ames" <gr...@remulak.net>
> Sent: Monday, October 01, 2001 9:44 AM
>
> > ... daedalus's config file contains
> >
> > AddHandler send-as-is asis
> >
> > That says that if /search.html is requested, and file
> > <docroot>/search.html.asis exists, it is a match and it to be served by
> > the handler who understands the "send-as_is" string (mod_asis's
> > handler), without interference from other modules. That no longer
> > happens. We cannot put this code into production until it is fixed.
>
> This is the patch that would negotate handlers and filters.
This patch allows mod_asis to work again. Thanks!
> We still have no mechanism to 'quantify' the quality of one handler or
> filter over another. Funny that
>
> index.html 4000 bytes
> index.cgi 500 bytes
>
> will serve index.cgi, based on size, when the cpu impact of index.html is
> _significantly_ less expensive ;)
>
I don't know what to say about this situation when the URI is "index" or
/. My gut says this is just ambiguous and is a user error. Picking one
based on size seems pretty arbitrary. I hope we don't have a lot of
sites depending on this behavior.
Greg
Re: .asis handler isn't driven
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Dirk-Willem van Gulik" <di...@covalent.net>
Sent: Monday, October 01, 2001 1:37 PM
> I am trying your change at the moment by stepping through it with the
> debugger.; I am worried that it fails for the case where CGI is not only
> language authenticated but also on something else; say charset.
The example;
AddContentType text/html html
AddHandler default-handler html
works because text/html is part of the negotation. The file matching is
-set- by contenttype/language/charset etc, it is not -unset- by handler.
Bill
Re: .asis handler isn't driven
Posted by Dirk-Willem van Gulik <di...@covalent.net>.
On Mon, 1 Oct 2001, William A. Rowe, Jr. wrote:
> We are discussing the effect of <AddHandler somehandler ext> on
> negotiation. That handler isn't part of the calculation for negotation,
> therefore my patch from a few weeks ago stopped adding that extension to
> the list that was "automagically" acceptable to multiviews. The client
> must now present the ".ext" extension when submitting the request, or
> the file won't be served.
...
> DOES work today, with the change. Here, ".asis" is a mime type, so it
> goes the through mime type negotiation phase.
I am trying your change at the moment by stepping through it with the
debugger.; I am worried that it fails for the case where CGI is not only
language authenticated but also on something else; say charset.
Dw
Re: .asis handler isn't driven
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
Dirk,
we aren't discussing the <AddFoo content-value ext> directives,
those continue to work fine. And yes, it would be nice to add a bit of
server-side 'quality control' over negotiation (say, an additional
'multiplier' where 1.000 is as-requested, .500 would cut the client
assigned weight in half, etc.) That's a different topic, though.
We are discussing the effect of <AddHandler somehandler ext> on
negotiation. That handler isn't part of the calculation for negotation,
therefore my patch from a few weeks ago stopped adding that extension to
the list that was "automagically" acceptable to multiviews. The client
must now present the ".ext" extension when submitting the request, or
the file won't be served.
Ergo, the server will now ignore index.cgi if the user requests "index"
and <AddHandler cgi-script cgi> is the only 'association' for .cgi. If
the admin associates cgi through mime types, then yes, mod_negotiation
still evalutates "index.cgi" in a multiviewed request for "index".
So taking the .asis example;
AddMimeType httpd/send-as-is
DOES work today, with the change. Here, ".asis" is a mime type, so it
goes the through mime type negotiation phase.
Bill
----- Original Message -----
From: "Dirk-Willem van Gulik" <di...@covalent.net>
To: <de...@httpd.apache.org>
Sent: Monday, October 01, 2001 11:22 AM
Subject: Re: .asis handler isn't driven
>
>
> On Mon, 1 Oct 2001, William A. Rowe, Jr. wrote:
>
> > We still have no mechanism to 'quantify' the quality of one handler or
> > filter over another. Funny that
> >
> > index.html 4000 bytes
> > index.cgi 500 bytes
> >
> > will serve index.cgi, based on size, when the cpu impact of index.html is
> > _significantly_ less expensive ;)
>
> Well length is last -if all other things equal-; sourcce_quality is first.
> since you can associate quality with any mimetipe/extensions. And this
> will help you out for the common case. (As does the hardcoded 'set quality
> to 2 (or some other high value) on CGI_MAGICTYPE) when we have args,
> a post or some other indication of CGI).
>
> Having said this this may sound like a solved problem - this is however
> not a generic solution. As this variance space is not a normal 'ordered'
> space where 1>2 and 2>3 and you got nicely spaced values. In fact this
> space behaves more like a logarithmic one - where distance denses - and
> hence we have all those fiddle factiors; the 0.001f's and so on. Perhaps a
> rewrite is in order -where we use sequential ordering per mime dimension
> (i.e. lang,charset,encoding,lenght) with a *linear* cost function.
>
>
> Dw
>
>
>
Re: .asis handler isn't driven
Posted by Dirk-Willem van Gulik <di...@covalent.net>.
On Mon, 1 Oct 2001, William A. Rowe, Jr. wrote:
> We still have no mechanism to 'quantify' the quality of one handler or
> filter over another. Funny that
>
> index.html 4000 bytes
> index.cgi 500 bytes
>
> will serve index.cgi, based on size, when the cpu impact of index.html is
> _significantly_ less expensive ;)
Well length is last -if all other things equal-; sourcce_quality is first.
since you can associate quality with any mimetipe/extensions. And this
will help you out for the common case. (As does the hardcoded 'set quality
to 2 (or some other high value) on CGI_MAGICTYPE) when we have args,
a post or some other indication of CGI).
Having said this this may sound like a solved problem - this is however
not a generic solution. As this variance space is not a normal 'ordered'
space where 1>2 and 2>3 and you got nicely spaced values. In fact this
space behaves more like a logarithmic one - where distance denses - and
hence we have all those fiddle factiors; the 0.001f's and so on. Perhaps a
rewrite is in order -where we use sequential ordering per mime dimension
(i.e. lang,charset,encoding,lenght) with a *linear* cost function.
Dw
Re: .asis handler isn't driven
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Greg Ames" <gr...@remulak.net>
Sent: Monday, October 01, 2001 9:44 AM
> ... daedalus's config file contains
>
> AddHandler send-as-is asis
>
> That says that if /search.html is requested, and file
> <docroot>/search.html.asis exists, it is a match and it to be served by
> the handler who understands the "send-as_is" string (mod_asis's
> handler), without interference from other modules. That no longer
> happens. We cannot put this code into production until it is fixed.
This is the patch that would negotate handlers and filters.
We still have no mechanism to 'quantify' the quality of one handler or
filter over another. Funny that
index.html 4000 bytes
index.cgi 500 bytes
will serve index.cgi, based on size, when the cpu impact of index.html is
_significantly_ less expensive ;)
Bill
Index: modules/http/mod_mime.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/http/mod_mime.c,v
retrieving revision 1.63
diff -u -u -1 -0 -r1.63 mod_mime.c
--- modules/http/mod_mime.c 2001/09/08 05:50:12 1.63
+++ modules/http/mod_mime.c 2001/10/01 15:15:44
@@ -778,32 +778,35 @@
/* The following extensions are not 'Found'. That is, they don't
* make any contribution to metadata negotation, so they must have
* been explicitly requested by name.
*/
if (exinfo->handler && r->proxyreq == PROXYREQ_NONE) {
r->handler = exinfo->handler;
+ found = 1;
}
/* XXX Two significant problems; 1, we don't check to see if we are
* setting redundant filters. 2, we insert these in the types config
* hook, which may be too early (dunno.)
*/
if (exinfo->input_filters && r->proxyreq == PROXYREQ_NONE) {
const char *filter, *filters = exinfo->input_filters;
while (*filters
&& (filter = ap_getword(r->pool, &filters, ';'))) {
ap_add_input_filter(filter, NULL, r, r->connection);
}
+ found = 1;
}
if (exinfo->output_filters && r->proxyreq == PROXYREQ_NONE) {
const char *filter, *filters = exinfo->output_filters;
while (*filters
&& (filter = ap_getword(r->pool, &filters, ';'))) {
ap_add_output_filter(filter, NULL, r, r->connection);
}
+ found = 1;
}
}
if (found)
found_metadata = 1;
else
*((const char **) apr_array_push(exception_list)) = ext;
}
Re: .asis handler isn't driven
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Greg Ames" <gr...@remulak.net>
Sent: Monday, October 01, 2001 9:44 AM
> "William A. Rowe, Jr." wrote:
> >
> > Greg, this isn't an error, and the early "Success" was a catastrophic
> > failure for many cases.
>
> Sir, you are mistaken. daedalus's config file contains
>
> AddHandler send-as-is asis
>
> That says that if /search.html is requested, and file
> <docroot>/search.html.asis exists, it is a match and it to be served by
> the handler who understands the "send-as_is" string (mod_asis's
> handler), without interference from other modules. That no longer
> happens. We cannot put this code into production until it is fixed.
Then we need to decide my other message.
How do you negotatate a request for "search" when there are;
search.shtml
search.cgi
search.asis
sitting in a directory? How do you express a preference in the configuration
between these variants?
Answer; Apache 1.3/prior 2.0 decided by the size of those three files.
Is that adaquate?
> > If a user of 1.3/earlier 2.0 copied index.html to index.html.bak, and
> > added a new paragraph to index.html, then queried index.html ...
> >
> > index.html.bak was returned, since the file was _smaller_.
>
> I agree...that's clearly wrong. But so is the current fix.
There are two issues. One - we used to serve some unrecognized extensions.
I think we all agree that's bogus, and it is fixed.
The other issue is "Negotating" handlers (and/or Filter'ed files). I believe
those too are bogus, but there's a difference of opinion on that point.
Let's limit the discussion then to that sole issue.
> > Any extension that A) was not requested, or B) is not negotatied
> > is not eligable to be served.
>
> Please take a look at this:
>
> http://httpd.apache.org/docs-2.0/mod/mod_asis.html
>
> This shows an example of a .asis file being used to redirect a URL which
> has moved. That's how we are using it on apache.org. It would be
> useless if the user had to type in a new URL
> (http://www.apache.org/search.html.asis) to get a match. The point is
> to allow the old URI (/search.html) to match the
> <docroot>/search.html.asis file, which contains the proper headers to
> redirect the user to the new location.
Agreed!!! Whatever conclusion we come to today, the docs must reflect.
How do we tell the user which mod_negotation will choose between;
index.html.asis
index.html
???
Bill
Re: .asis handler isn't driven
Posted by Greg Ames <gr...@remulak.net>.
"William A. Rowe, Jr." wrote:
>
> Greg, this isn't an error, and the early "Success" was a catastrophic
> failure for many cases.
Sir, you are mistaken. daedalus's config file contains
AddHandler send-as-is asis
That says that if /search.html is requested, and file
<docroot>/search.html.asis exists, it is a match and it to be served by
the handler who understands the "send-as_is" string (mod_asis's
handler), without interference from other modules. That no longer
happens. We cannot put this code into production until it is fixed.
> If a user of 1.3/earlier 2.0 copied index.html to index.html.bak, and
> added a new paragraph to index.html, then queried index.html ...
>
> index.html.bak was returned, since the file was _smaller_.
I agree...that's clearly wrong. But so is the current fix.
> Any extension that A) was not requested, or B) is not negotatied
> is not eligable to be served.
Please take a look at this:
http://httpd.apache.org/docs-2.0/mod/mod_asis.html
This shows an example of a .asis file being used to redirect a URL which
has moved. That's how we are using it on apache.org. It would be
useless if the user had to type in a new URL
(http://www.apache.org/search.html.asis) to get a match. The point is
to allow the old URI (/search.html) to match the
<docroot>/search.html.asis file, which contains the proper headers to
redirect the user to the new location.
Greg
Re: Apache 1.3 :: Not-a-bug: .asis handler
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Justin Erenkrantz" <je...@ebuilt.com>
Sent: Tuesday, October 02, 2001 1:04 PM
> On Tue, Oct 02, 2001 at 12:07:46PM -0500, William A. Rowe, Jr. wrote:
> > It's bitten several folks. It's been written up on bugtraq as an outstanding
> > case. There are a dozen variations of cause and effect. But whatever, you are
> > the RM, and nobody can veto a release.
>
> Pardon my ignorance, but why can't someone veto a release if they feel
> it is the wrong time to do so? -- justin
http://dev.apache.org/guidelines.html
[-1 Votes]
No. On issues where consensus is required, this vote counts as a veto.
An action item requiring consensus approval must receive at least
3 binding +1 votes and no vetos. An action item requiring majority
approval must receive at least 3 binding +1 votes and more +1 votes
than -1 votes (i.e., a majority with a minimum quorum of three positive
votes). All other action items are considered to have lazy approval until
someone votes -1, after which point they are decided by either consensus
or a majority vote, depending upon the type of action item.
Release Testing
Majority approval is required before the tarball can be publically released.
So releasing a version of Apache is by Majority, not by Consensus.
And it is designed that way --- no one individual can stand in the way of
moving forward with changes. The only reason my changes thus far are in
the 1.3.21 plan is that they have been on the table for some time, and the
RM concurred with including them (even by lazy concensus, nobody objected
when they were introduced into STATUS.)
Re: Apache 1.3 :: Not-a-bug: .asis handler
Posted by Ben Hyde <bh...@pobox.com>.
Justin Erenkrantz wrote:
> Pardon my ignorance, but why can't someone veto a release if they feel
> it is the wrong time to do so? -- justin
We have a mess of rules/traditions that act to prevent
obstructionism and push people toward constructive
argument and constructive actions. Releasing is always
a matter of tearing the damn thing out of the hands of
the evil demon "one more really really important thing".
- ben
Re: Apache 1.3 :: Not-a-bug: .asis handler
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Tue, Oct 02, 2001 at 12:07:46PM -0500, William A. Rowe, Jr. wrote:
> It's bitten several folks. It's been written up on bugtraq as an outstanding
> case. There are a dozen variations of cause and effect. But whatever, you are
> the RM, and nobody can veto a release.
Pardon my ignorance, but why can't someone veto a release if they feel
it is the wrong time to do so? -- justin
Re: Apache 1.3 :: Not-a-bug: .asis handler
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Bill Stoddard" <bi...@wstoddard.com>
Sent: Monday, October 01, 2001 3:03 PM
> This is looking more and more like config funkiness as opposed to a serious
> code defect. Unless I see something to change my mind, I am not inclined to
> attempt to fix this in the 1.3 code base.
Whatever. I advertised the fix, I couldn't care less if anyone backports it.
It's bitten several folks. It's been written up on bugtraq as an outstanding
case. There are a dozen variations of cause and effect. But whatever, you are
the RM, and nobody can veto a release.
The problem is that each of the modules, mime, negotation, and autoindex, as
well as the default handler have all contributed to this thorny problem.
Yes - you can call it config error. But I'd argue that not being able to
see the whole picture doesn't make this a config error; our inability to
unlock the 'secrets' of our modules interaction means that the admin has no
hope of ever understanding this.
We advertised mod_negotation as a real module, not 'experimental'. If our
own modules interact impolitely, we should re-relegate it to experimental.
BTW - I agree with keeping the 'found' match logic for matching AddHandler
extensions in 1.3 - to retain backwards brokenness and to meet the "prinicpal
of least surprize" test. That's not my opinion on 2.0, but that's another
thread. So "index.html.asis" should continue to match "index.html" for 1.3.
Bill
Re: Not-a-bug: .asis handler isn't driven
Posted by Bill Stoddard <bi...@wstoddard.com>.
> Still working on recreating this...
>
> > > The sub_req for index.html.temp is destroyed because
> > > sub_req->content_type == NULL, which looks correct to me.
> >
> > Try index.html.en.temp - which may have been what I was thinking of.
>
> .temp is the last extension inspected by mod_mime. If temp is not in any of the tables
> (content-type, charset, content-language, content-encoding) and is not a special
handler,
> the sub_req->content_type is set to NULL which excludes the file from being negotiated.
>
> > Assure that it becomes the last file in the directory listing.
> >
> > The specific bug folks observed was that .lang.charset would be served,
> > even though charset wasn't negotiated.
>
> Ditto. If charset is the last extension and it is not configured, the file will not be
> considered for negotiation.
>
index.html.yadda.Big5 will not be considered for negotiation because, as you have pointed
out, the content type will be lost (reset to NULL) by mod_mime during the processing of
the unknown 'yadda' extension. A NULL content_type prevents the file from being added to
the list of negotiable files. There is one exception...
AFAIK, the only way this file can be added to the list of negotiable files (for use by
mod_negotiate) is if the directory has a ForceType in effect. ForceType will cause
mod_mime to force set the content_type to the configured value.
This is looking more and more like config funkiness as opposed to a serious code defect.
Unless I see something to change my mind, I am not inclined to attempt to fix this in the
1.3 code base.
Bill
Re: Not-a-bug: .asis handler isn't driven
Posted by Bill Stoddard <bi...@wstoddard.com>.
Still working on recreating this...
> > The sub_req for index.html.temp is destroyed because
> > sub_req->content_type == NULL, which looks correct to me.
>
> Try index.html.en.temp - which may have been what I was thinking of.
.temp is the last extension inspected by mod_mime. If temp is not in any of the tables
(content-type, charset, content-language, content-encoding) and is not a special handler,
the sub_req->content_type is set to NULL which excludes the file from being negotiated.
> Assure that it becomes the last file in the directory listing.
>
> The specific bug folks observed was that .lang.charset would be served,
> even though charset wasn't negotiated.
Ditto. If charset is the last extension and it is not configured, the file will not be
considered for negotiation.
>
> How isn't content_type set, am I thinking of .temp.html?
This will cause content_type to be set and the file will be considered for negotiation,
regardless of whether the previous extensions are known or unknown. I have not managed to
get index.html.en.temp.html (or similar) to serve up but they -are- placed in the list of
negotiable files. So this looks to be a possible failure scenario even though I have not
been able to reproduce it.
Any of this ring any bells?
Bill
Re: Not-a-bug: .asis handler isn't driven
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Bill Stoddard" <bi...@wstoddard.com>
Sent: Monday, October 01, 2001 11:35 AM
>
> The sub_req for index.html.temp is destroyed because
> sub_req->content_type == NULL, which looks correct to me.
Try index.html.en.temp - which may have been what I was thinking of.
Assure that it becomes the last file in the directory listing.
The specific bug folks observed was that .lang.charset would be served,
even though charset wasn't negotiated.
How isn't content_type set, am I thinking of .temp.html? I acknowledge
that this is _very_ tricky to reproduce. I went *30* rounds with one
reporter, trying to duplicate their conditions. I would succeed on and
off, the issues interact with one another to produce unexpected results.
In any case, this first example is the bug I've pointed you at.
The second case that Greg Ames is complaining of is the question,
do we take .asis (or any associated handler) and treat as-negotated.
Re: Not-a-bug: .asis handler isn't driven
Posted by Bill Stoddard <bi...@wstoddard.com>.
Testing in 1.3...
> 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
> index.html.fr 1632 bytes
>
> if the user's Accept-Language header is simply en, and they request
> index.html, they will get the .en variant.
Yep.
> Accept-Language of fr
> will return the french variant.
Yep.
> Accept-Language of anything else
> returns Not Acceptable,
Yep.
> 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.
Yep.
>
> Now, Admin copies index.html.fr to index.html.temp. Starts editing,
> deletes two paragraphs...
>
> index.html.temp 1039 bytes
Done.
>
> User requests index.html with AcceptLanguage en or fr. They aught
> to get the right file.
Yep.
> User has another Accept-Language. They MAY
> get index.html.temp, because the others failed, and .temp inserts no
> no language identification to reject.
Set IE to request Basque [eu] and received 406 Not Acceptable which is correct.
> They provide no Accept-Language,
> and they _will_ get index.html.temp, based on size alone.
Nope, I don't get index.html.temp. I get index.html.en. In fact, if I attach a debugger
and watch what mod_negotiation is doing, it does not even allow index.html.temp to be
considered for negotiation because the content_type is NULL. Here is the code...
while ((dir_entry = readdir(dirp))) {
request_rec *sub_req;
/* Do we have a match? */
if (strncmp(dir_entry->d_name, filp, prefix_len)) {
continue;
}
if (dir_entry->d_name[prefix_len] != '.') {
continue;
}
/* Yep. See if it's something which we have access to, and
* which has a known type and encoding (as opposed to something
* which we'll be slapping default_type on later).
*/
sub_req = ap_sub_req_lookup_file(dir_entry->d_name, r);
/* If it has a handler, we'll pretend it's a CGI script,
* since that's a good indication of the sort of thing it
* might be doing.
*/
if (sub_req->handler && !sub_req->content_type) {
sub_req->content_type = CGI_MAGIC_TYPE;
}
/* HTTP_FORBIDDEN is returned, e.g., if the path length limit was exceeded */
/* HTTP_OK does NOT necessarily mean that the file is really readable! */
if (sub_req->status == HTTP_OK)
forbidden.all = 0;
else if (sub_req->status == HTTP_FORBIDDEN)
forbidden.any = 1;
if (sub_req->status != HTTP_OK || !sub_req->content_type) {
ap_destroy_sub_req(sub_req);
continue;
}
The sub_req for index.html.temp is destroyed because sub_req->content_type == NULL, which
looks correct to me.
Bill
Re: Not-a-bug: .asis handler isn't driven
Posted by Joshua Slive <sl...@commerce.ubc.ca>.
On Mon, 1 Oct 2001, William A. Rowe, Jr. wrote:
> 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.
>
I've only read this thread very quickly (just catching up on mail),
but let me reiterate a point that I believe has been mentioned briefly:
Multiviews has two purposes in 1.3: It can be used for negotiated
documents, or it can be used to hide implementation details.
The first part is obvious. To be specific about the second part,
the idea is:
1. File extensions are a convenient way to store/configure
meta-information about resources.
2. The URLs do not need to contain this meta-information, and in fact
often SHOULD NOT contain it.
For example, the URL may be
http://example.com/info
This may start off as info.html, but later an ssi document is substituted
so it becomes info.shtml, and later the url is changed so info.asis is
substituted. The client doesn't care about all this garbage, since it can
just request /info and get the correct thing.
Yes, it is bogus that a selection can be made based on length. It is a
configuration error to put have two different files which may be selected
by multi-views but are not "negotiable" with the client. Either an error
could be returned, or we could just document that the selection is
arbitrary in that case.
Joshua.
Not-a-bug: .asis handler isn't driven
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
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
index.html.fr 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 index.html.fr 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
served.
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.
Bill
Re: .asis handler isn't driven
Posted by Bill Stoddard <bi...@wstoddard.com>.
Bill,
I didn't have any time to look at this over the weekend, but as of Friday afternoon, I
have not been able to recreate this problem in Apache 1.3.
Bill
> Greg, this isn't an error, and the early "Success" was a catastrophic
> failure for many cases.
>
> If a user of 1.3/earlier 2.0 copied index.html to index.html.bak, and
> added a new paragraph to index.html, then queried index.html ...
>
> index.html.bak was returned, since the file was _smaller_.
>
> Any extension that A) was not requested, or B) is not negotatied
> is not eligable to be served.
>
> [There is a weakness. We need to evaluate the exception list by
> component, right now we simply strcmp. There is a note in status to
> that effect. E.g. requesting index.bak -should- match index.html.bak,
> but it wouldn't. Although we can test -in-order-, we simply need to
> check that each extension that didn't match was an extension of the
> requested filename.]
>
> Bill
>
>
> ----- Original Message -----
> From: "Greg Ames" <gr...@remulak.net>
> To: <de...@httpd.apache.org>
> Sent: Friday, September 28, 2001 4:25 PM
> Subject: .asis handler isn't driven
>
>
> > www.apache.org was recently changed so that www.apache.org/search.html
> > became search.html.asis .
> > That document contains a 301 Moved Permanantly response, referring to
> > http://search.apache.org/ .
> >
> > It works fine with 2.0.24, but fails with the current HEAD with:
> >
> > [Thu Sep 27 13:49:14 2001] [error] [client 32.97.136.236] Negotiation:
> > discovered file(s) matching request: /www/www.apache.org/search.html
> > (None could be negotiated).
> >
> > daedalus's config file contains:
> >
> > AddHandler send-as-is asis
> >
> > The log entry is created by read_types_multi() in mod_negotiation,
> > called by its type checker phase. Shortly before this log entry, there
> > is a loop which attempts to match prefixes of directory entries against
> > "exceptions" discovered by mod_mime. The closest we ever come to a
> > match in this loop is comparing "search.html" from the dir to
> > "search.asis" from the exceptions list. There is some code that notices
> > that sub_req->handler and ->content_type are non-null, but that isn't
> > enough to make it happy. We eventually return HTTP_NOT_FOUND from
> > read_types_multi(), so the asis handler never gets a shot the request.
> >
> > I suspect mod_mime more than mod_negotiation, because the changes to the
> > latter in the type checker seem pretty innocent since 2.0.24. But I
> > don't know how this interface is supposed to work.
> >
> > After read_types_multi() runs a subrequest for search.html.asis,
> > sub_req->handler == "send-as-is" and sub_req->content_type ==
> > "text/html". I would think that's about all the type checking phase
> > needs, and read_types_multi() should say
> > "OK, mod_mime knows the full scoop for this variant, so I should be
> > happy with it too."
> >
> > Greg
> >
>