You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by gr...@apache.org on 2001/10/09 03:45:20 UTC
cvs commit: httpd-2.0/modules/http mod_mime.c
gregames 01/10/08 18:45:20
Modified: modules/http mod_mime.c
Log:
allow file extentions specified by AddHandler, AddInputFilter, and
AddOutputFilter to be ignored when matching the URI.
Submitted by: Bill Rowe
Revision Changes Path
1.65 +3 -0 httpd-2.0/modules/http/mod_mime.c
Index: mod_mime.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/http/mod_mime.c,v
retrieving revision 1.64
retrieving revision 1.65
diff -u -r1.64 -r1.65
--- mod_mime.c 2001/10/02 21:13:42 1.64
+++ mod_mime.c 2001/10/09 01:45:20 1.65
@@ -780,6 +780,7 @@
*/
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
@@ -791,6 +792,7 @@
&& (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;
@@ -798,6 +800,7 @@
&& (filter = ap_getword(r->pool, &filters, ';'))) {
ap_add_output_filter(filter, NULL, r, r->connection);
}
+ found = 1;
}
}
Re: cvs commit: httpd-2.0/modules/http mod_mime.c
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "William A. Rowe, Jr." <wr...@covalent.net>
Sent: Wednesday, October 10, 2001 12:40 AM
> From: "Greg Ames" <gr...@remulak.net>
> Sent: Tuesday, October 09, 2001 12:33 PM
>
> > "William A. Rowe, Jr." wrote:
> > >
> > > What is the multiview mechanics?
> >
> > K.I.S.S. Why do we need multiviews for handlers etc? Are any users
> > asking for this support? What can I do with it that I can't do
> > otherwise? How would the documentation for such a feature read?
>
> MultiviewHandlerExtensions on|off
> MultiviewFilterExtensions on|off
Then how about this;
MultiviewsMatch NegotiatedOnly [my preference]
MultiviewsMatch Handlers [apache 1.3 behavior]
MultiviewsMatch Handlers Filters [your preference]
MultiviewsMatch Filters [why? because you could :]
Does this solve our entire debate?
Bill
Index: modules/http/mod_mime.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/http/mod_mime.c,v
retrieving revision 1.65
diff -u -r1.65 mod_mime.c
--- modules/http/mod_mime.c 2001/10/09 01:45:20 1.65
+++ modules/http/mod_mime.c 2001/10/10 16:07:38
@@ -110,6 +110,11 @@
char *output_filters; /* Added with AddOutputFilter... */
} extension_info;
+#define MULTIMATCH_UNSET 0
+#define MULTIMATCH_NEGOTIATED 1
+#define MULTIMATCH_HANDLERS 2
+#define MULTIMATCH_FILTERS 4
+
typedef struct {
apr_hash_t *extension_mappings; /* Map from extension name to
* extension_info structure */
@@ -117,8 +122,10 @@
apr_array_header_t *remove_mappings; /* A simple list, walked once */
char *default_language; /* Language if no AddLanguage ext found */
- /* Due to the FUD about JS and charsets
- * default_charset is actually in src/main */
+
+ int multimatch; /* Extensions to include in multiview matching
+ * for filenames, e.g. Filters and Handlers
+ */
} mime_dir_config;
typedef struct param_s {
@@ -151,6 +158,8 @@
new->default_language = NULL;
+ new->multimatch = MULTIMATCH_UNSET;
+
return new;
}
/*
@@ -267,6 +276,9 @@
new->default_language = add->default_language ?
add->default_language : base->default_language;
+ new->multimatch = (add->multimatch != MULTIMATCH_UNSET) ?
+ add->multimatch : base->multimatch;
+
return new;
}
@@ -337,6 +349,32 @@
return NULL;
}
+static const char *multiviews_match(cmd_parms *cmd, void *m_,
+ const char *include)
+{
+ mime_dir_config *m = (mime_dir_config *) m_;
+
+ if (strcasecmp(include, "NegotiatedOnly") == 0) {
+ if (m->multimatch & ~MULTIMATCH_NEGOTIATED)
+ return "Negotiated is incompatible with Filters and Handlers";
+ m->multimatch |= MULTIMATCH_NEGOTIATED;
+ }
+ else if (strcasecmp(include, "Filters") == 0) {
+ if (m->multimatch & MULTIMATCH_NEGOTIATED)
+ return "Filters is incompatible with Negotiated";
+ m->multimatch |= MULTIMATCH_FILTERS;
+ }
+ else if (strcasecmp(include, "Handlers") == 0) {
+ if (m->multimatch & MULTIMATCH_NEGOTIATED)
+ return "Handlers is incompatible with Negotiated";
+ m->multimatch |= MULTIMATCH_HANDLERS;
+ }
+ else
+ return "Unrecognized option";
+
+ return NULL;
+}
+
static const command_rec mime_cmds[] =
{
AP_INIT_ITERATE2("AddCharset", add_extension_info,
@@ -363,6 +401,8 @@
AP_INIT_TAKE1("DefaultLanguage", ap_set_string_slot,
(void*)APR_XtOffsetOf(mime_dir_config, default_language), OR_FILEINFO,
"language to use for documents with no other language file extension"),
+AP_INIT_ITERATE("MultiviewsMatch", multiviews_match, NULL, OR_FILEINFO,
+ "Handlers and/or Filters, or NegotiatedOnly (neither)"),
AP_INIT_ITERATE("RemoveCharset", remove_extension_info,
(void *)APR_XtOffsetOf(extension_info, charset_type), OR_FILEINFO,
"one or more file extensions"),
@@ -780,7 +820,8 @@
*/
if (exinfo->handler && r->proxyreq == PROXYREQ_NONE) {
r->handler = exinfo->handler;
- found = 1;
+ if (conf->multimatch & MULTIMATCH_HANDLERS)
+ 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
@@ -792,7 +833,8 @@
&& (filter = ap_getword(r->pool, &filters, ';'))) {
ap_add_input_filter(filter, NULL, r, r->connection);
}
- found = 1;
+ if (conf->multimatch & MULTIMATCH_FILTERS)
+ found = 1;
}
if (exinfo->output_filters && r->proxyreq == PROXYREQ_NONE) {
const char *filter, *filters = exinfo->output_filters;
@@ -800,7 +842,8 @@
&& (filter = ap_getword(r->pool, &filters, ';'))) {
ap_add_output_filter(filter, NULL, r, r->connection);
}
- found = 1;
+ if (conf->multimatch & MULTIMATCH_FILTERS)
+ found = 1;
}
}
Re: cvs commit: httpd-2.0/modules/http mod_mime.c
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Greg Ames" <gr...@remulak.net>
Sent: Tuesday, October 09, 2001 12:33 PM
> "William A. Rowe, Jr." wrote:
> >
> > What is the multiview mechanics?
>
> K.I.S.S. Why do we need multiviews for handlers etc? Are any users
> asking for this support? What can I do with it that I can't do
> otherwise? How would the documentation for such a feature read?
MultiviewHandlerExtensions on|off
MultiviewFilterExtensions on|off
:-?
Bill
Re: cvs commit: httpd-2.0/modules/http mod_mime.c
Posted by jo...@slive.ca.
On Tue, 9 Oct 2001, Greg Ames wrote:
>
> Externalizing a weighting mechanism for handlers or filters is
> over-engineering IMO. I have yet to see a good use case to justify this
> additional complexity.
>
> Certainly, negotiation is needed for languages, charsets, encodings and
> types. It's nice that we were able to use some of those internals to
> allow implicit matches for handler and filter filename extentions.
> However, just because we're taking advantage of the plumbing doesn't
> mean we need full externalized support for multiviews for this stuff.
I completely agree with Greg on this and all the rest of his comments on
this topic. I have never understood why this is an issue for OtherBill.
Joshua.
Re: cvs commit: httpd-2.0/modules/http mod_mime.c
Posted by Greg Ames <gr...@remulak.net>.
"William A. Rowe, Jr." wrote:
> Did the type definition I provided for .asis not work correctly to
> also resolve your problem? The beauty for .asis, the content type
> is completely replaced by the .asis body ;)
Sorry, but I don't know what you're talking about here. I'll go search
the archives and/or check to insure that the problem still exists
without this patch.
> I'm vetoing this patch until some mechansim for weighting different
> multimatch targets by handler or by filter is introduced.
Externalizing a weighting mechanism for handlers or filters is
over-engineering IMO. I have yet to see a good use case to justify this
additional complexity.
Certainly, negotiation is needed for languages, charsets, encodings and
types. It's nice that we were able to use some of those internals to
allow implicit matches for handler and filter filename extentions.
However, just because we're taking advantage of the plumbing doesn't
mean we need full externalized support for multiviews for this stuff.
> Just because it 'worked' on 1.3 doesn't make it the right behavior.
It is a fine behavior. Rejecting the request when there are ambiguous
matches for handlers etc. might have been even finer in retrospect, but
now we have a precedent.
> You don't need to back out, we just need to solve before 2.0.26.
What's the urgency? We have enough real problems to work on. I'm still
not ready to try the current HEAD in production on daedalus, but we are
getting closer.
> What is the multiview mechanics?
K.I.S.S. Why do we need multiviews for handlers etc? Are any users
asking for this support? What can I do with it that I can't do
otherwise? How would the documentation for such a feature read?
Greg
Re: cvs commit: httpd-2.0/modules/http mod_mime.c
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Rodent of Unusual Size" <Ke...@Golux.Com>
Sent: Wednesday, October 10, 2001 3:16 PM
> "William A. Rowe, Jr." wrote:
> >
> > If the administrator uses AddHandler for
> > .cgi, .php, .shtml and .foo, and all four
> > of these files exist in /htdocs,
> > which one should mod_negotation elect?
>
> And what about extensions that have meaning to both,
> hmm? Such as AddHander server-parsed .html?
They are accepted. Handler/Filter recognition never _revokes_
the found attribute.
> > Since we have no mechanics to assign any preference,
> > I depreciated the broken behavior.
>
> The inability to specify a preference is *not* broken.
They can specify a preference, by attaching any _negotiation_
to the file extention.
> > If the user browses to index.cgi, index.php, index.shtml,
> > or index.foo, they will get the correct content. If they
> > browse to index, they would find a Not Found.
>
> Now *that's* broken, and badly. What they should get is
> a 300 Multiple Choices.
Undoubtedly.
> > Greg Ames reverted to the 1.3 behavior, where they will
> > get the smallest of the four files (of these four Handler
> > variants.) This was wrong before, and is certainly wrong
> > for 2.0 forward.
>
> I disagree that it was necessarily wrong. Suboptimal,
> but not automatically wrong.
Not suboptimal. Try erratic and unpredictable [in the mind of
the typical administrator.]
> > When we allow the administrator to prioritize between
> > these handler/filter assignments, then we can permit
> > such filename extensions to participate in Multiviews.
> > Until then, this behavior is unacceptable.
>
> Strong words.. and they seem to assume that extensions
> will only participate in the content-type OR the handler/filter
> axes, but not both. Which is a bogus assumption (I say
> that because I use 'em that way myself).
No, as I mentioned up front, we don't demote the file's negotated
status, and we can add filter(s) and handler definitions to that
same extention.
> > Several admin-type folks have posted to the list that
> > they agree
> :
> > and choosing the 'wrong file' from negotation is a bug,
> > not misconfiguration.
>
> Oh, bollocks. :-) If there are multiple files that
> mee the criteria, *none* of them are the 'wrong file'
> (yes, I noticed the quotes). They are all equally
> acceptable to the client, and the server is permitted
> to break the tie however it likes.
But they are not necessarily intended to be served by the fellow
or gal who populated that web directory, and this is one of those
strange places where the seperation between maintaining content
and administering the web server can introduce tons of confusion.
See my patch from this morning, see if it 'fits the bill' from your
vantage point.
Re: cvs commit: httpd-2.0/modules/http mod_mime.c
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"William A. Rowe, Jr." wrote:
>
> If the administrator uses AddHandler for
> .cgi, .php, .shtml and .foo, and all four
> of these files exist in /htdocs,
> which one should mod_negotation elect?
And what about extensions that have meaning to both,
hmm? Such as AddHander server-parsed .html?
> Since we have no mechanics to assign any preference,
> I depreciated the broken behavior.
The inability to specify a preference is *not* broken.
> If the user browses to index.cgi, index.php, index.shtml,
> or index.foo, they will get the correct content. If they
> browse to index, they would find a Not Found.
Now *that's* broken, and badly. What they should get is
a 300 Multiple Choices.
> Greg Ames reverted to the 1.3 behavior, where they will
> get the smallest of the four files (of these four Handler
> variants.) This was wrong before, and is certainly wrong
> for 2.0 forward.
I disagree that it was necessarily wrong. Suboptimal,
but not automatically wrong.
> When we allow the administrator to prioritize between
> these handler/filter assignments, then we can permit
> such filename extensions to participate in Multiviews.
> Until then, this behavior is unacceptable.
Strong words.. and they seem to assume that extensions
will only participate in the content-type OR the handler/filter
axes, but not both. Which is a bogus assumption (I say
that because I use 'em that way myself).
> Several admin-type folks have posted to the list that
> they agree
:
> and choosing the 'wrong file' from negotation is a bug,
> not misconfiguration.
Oh, bollocks. :-) If there are multiple files that
mee the criteria, *none* of them are the 'wrong file'
(yes, I noticed the quotes). They are all equally
acceptable to the client, and the server is permitted
to break the tie however it likes.
--
#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: cvs commit: httpd-2.0/modules/http mod_mime.c
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Rodent of Unusual Size" <Ke...@Golux.Com>
Sent: Tuesday, October 09, 2001 6:06 AM
> "William A. Rowe, Jr." wrote:
> >
> > And size matters, but it's irrelevant if we are
> > choosing between cgi-generated content, (filter)
> > parsed content and static content.
>
> I'm not quite sure what the above has to do with
> mod_mime. If you're talking about negociation, though:
>
> Not quite, I don't think. Leave the generation method
> out of the equation; it's irrelevant. It's the 'quality'
> of the content that matters, not how it's generated.
> The Webmaster may decide to assign a higher quality to
> static content (which also has a better performance),
> but he may not. Please get it out of your head that the
> impact of producing the content is automatically related
> to which is the 'better' variant; we can set that up as our
> default if the Webmaster doesn't assign quality values,
> but it is *not* automatically the case.
I expressed my personal preference for a website I adminster. That
has nothing to do with what another administrator/web author would choose
to do.
Today there is no means of prioritizing negotiated Handler/Filter documents.
My reorg of mod_mime+mod_negotation stopped auto-recognizing file extensions
that don't participate in negotation (those that _only_ set handler/filter.)
They still set a filter or hander. If the administrator uses AddHandler for
.cgi, .php, .shtml and .foo, and all four of these files exist in /htdocs,
which one should mod_negotation elect? Since we have no mechanics to assign
any preference, I depreciated the broken behavior. If the user browses to
index.cgi, index.php, index.shtml, or index.foo, they will get the correct
content. If they browse to index, they would find a Not Found.
Greg Ames reverted to the 1.3 behavior, where they will get the smallest of
the four files (of these four Handler variants.) This was wrong before, and
is certainly wrong for 2.0 forward.
When we allow the administrator to prioritize between these handler/filter
assignments, then we can permit such filename extensions to participate in
Multiviews. Until then, this behavior is unacceptable. Several admin-type
folks have posted to the list that they agree, the proliferator of a given
directory isn't necessarily the administrator, and choosing the 'wrong file'
from negotation is a bug, not misconfiguration.
Bill
Re: cvs commit: httpd-2.0/modules/http mod_mime.c
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"William A. Rowe, Jr." wrote:
>
> And size matters, but it's irrelevant if we are
> choosing between cgi-generated content, (filter)
> parsed content and static content.
I'm not quite sure what the above has to do with
mod_mime. If you're talking about negociation, though:
Not quite, I don't think. Leave the generation method
out of the equation; it's irrelevant. It's the 'quality'
of the content that matters, not how it's generated.
The Webmaster may decide to assign a higher quality to
static content (which also has a better performance),
but he may not. Please get it out of your head that the
impact of producing the content is automatically related
to which is the 'better' variant; we can set that up as our
default if the Webmaster doesn't assign quality values,
but it is *not* automatically the case.
--
#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: cvs commit: httpd-2.0/modules/http mod_mime.c
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: <gr...@apache.org>
Sent: Monday, October 08, 2001 8:45 PM
> gregames 01/10/08 18:45:20
>
> Modified: modules/http mod_mime.c
> Log:
> allow file extentions specified by AddHandler, AddInputFilter, and
> AddOutputFilter to be ignored when matching the URI.
>
> Submitted by: Bill Rowe
I aught to revert this patch, simply for your citing my name ;)
Look, 1.3 followed this behavior. Roy and I have both pointed out that
by using content type drivers (which can be negotiated), instead of these
unnegotated handlers/filters, this will work just fine. And I expressed
I'm entirely against the patch, although I provided it for clarity.
Did the type definition I provided for .asis not work correctly to
also resolve your problem? The beauty for .asis, the content type
is completely replaced by the .asis body ;)
I'm vetoing this patch until some mechansim for weighting different
multimatch targets by handler or by filter is introduced. Some folks
had good suggestions, and Roy pointed out that we do so already with
content-type oriented negotation. I have no opinion one way or the
other on that side of the issue.
Just because it 'worked' on 1.3 doesn't make it the right behavior.
And size matters, but it's irrelevant if we are choosing between
cgi-generated content, (filter) parsed content and static content.
You don't need to back out, we just need to solve before 2.0.26. What
is the multiview mechanics?
[BTW - .asis should be the very highest priority, if the server can
find .asis content, it should nearly _always_ be the default.]
Bill
Re: cvs commit: httpd-2.0/modules/http mod_mime.c
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: <gr...@apache.org>
Sent: Monday, October 08, 2001 8:45 PM
> gregames 01/10/08 18:45:20
>
> Modified: modules/http mod_mime.c
> Log:
> allow file extentions specified by AddHandler, AddInputFilter, and
> AddOutputFilter to be ignored when matching the URI.
>
> Submitted by: Bill Rowe
I aught to revert this patch, simply for your citing my name ;)
Look, 1.3 followed this behavior. Roy and I have both pointed out that
by using content type drivers (which can be negotiated), instead of these
unnegotated handlers/filters, this will work just fine. And I expressed
I'm entirely against the patch, although I provided it for clarity.
Did the type definition I provided for .asis not work correctly to
also resolve your problem? The beauty for .asis, the content type
is completely replaced by the .asis body ;)
I'm vetoing this patch until some mechansim for weighting different
multimatch targets by handler or by filter is introduced. Some folks
had good suggestions, and Roy pointed out that we do so already with
content-type oriented negotation. I have no opinion one way or the
other on that side of the issue.
Just because it 'worked' on 1.3 doesn't make it the right behavior.
And size matters, but it's irrelevant if we are choosing between
cgi-generated content, (filter) parsed content and static content.
You don't need to back out, we just need to solve before 2.0.26. What
is the multiview mechanics?
[BTW - .asis should be the very highest priority, if the server can
find .asis content, it should nearly _always_ be the default.]
Bill