httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (David Robinson)
Subject Re: slight API change
Date Sun, 17 Mar 1996 15:40:00 GMT
> On Sun, 10 Mar 1996, David Robinson wrote:
> > >So I've made, in a patch which I include below (since it's rather short),
> > >a slight change that should make this easier in the future: I've added a
> > >new member to request_rec, char *handler. This can be set, at any point
> > >during the request, to a string which Apache will key off of instead of
> > >content_type when it invokes a handler. If r->handler is empty, it will
> > >still use content_type, so this shouldn't affect anything currently in
> > >practice, but it does eliminate the need for type_checker hacks and
> > >"magic" MIME types for some things. The proxy module, for example, could 
> > >just say r->handler = "http-proxy";, and set up a handler for
> > >"http-proxy". (ideally, these non-content-type handlers would have no
> > >slashes, so as not to conflict with MIME types).
> > > 
> > > Shouldn't 'handler' be set by default from the filename, thus
> > > bypassing the whole magic mime-type stuff?
> No. Because there is no "default". And in most cases, you still want to 
> handle by mime-type. What it eliminates is the "magic" mime-type. 
> Non-magic types still exist.
> > Or to put it another way, how does your patch address the suggestion I
> > made in December?
> Thing is, your AddHandler is just another word for AddType. They're the
> same thing. And whether you call it a magic mime-type, or just some other
> name, they're also the same thing. What the patch does let you do is make
> a module that would do: 
> AddHandler cgi /cgi-bin/
> And have mod_cgi handle a handler named 'cgi'. This would function like
> ScriptAlias. It also allows commands like ScriptAlias to handle this
> internally, instead of using the forced_type hack mod_alias uses now - the
> uri-to-filename conversion stage can set a handler directly. 
> Maybe it's not perfect. Nothing is. But it's useful. I can think of at
> least two places in Apache where right now, it'd make the server run more
> cleanly: ScriptAlias and mod_proxy. And that's worth something.
> What it's designed to allow are things that act like directories instead 
> of like files, a la ScriptAlias. For example, a statistics module might 
> be activated with
> Statistics /stats
> And then it has a uri-to-filename translator that takes anything starting 
> with "/stats" and sets r->handler to "statistics". It then has a handler 
> called "statistics", which handles all the stats requests. Without this 
> patch, this cannot be done in Apache currently, without resorting to a 
> mime type hack.

I've read this quite a few times, and I hope I've understood what you are
getting at.

I realise now that we are trying to solve different problems.

What you are trying to do is force particular action for all files in
a particular directory. What I was trying to do was seperate actions from
document types. Unfortunately, your implementation of the former is only
a partial solution to the latter.

Now if you had implemented a ForceType directive, which fixed the mime
type for all files in a directory, e.g.

ForceType application/x-httpd-cgi /cgi-bin

Then I wouldn't have made the confusion. (This directive, BTW, could
be made functionally equivalent to your AddHandler directive, but without
introducing any new concepts.)

However, you want to add a 'handler' property to a file. I agree with this;
it is what I suggested in December. This avoids the overloading of the
mime type of the resource with the action a file invokes.

Now, your AddHandler directive only goes part way to implementing this; the
case where the action is deduced from the directory containing the file.
It does not implement the case where the action is deduced from the filename
itself; _that_ was what I was 'complaining' about. To get rid of magic
mime types, we need both parts of the solution. Clearly, in my message
of December I neglected the part that you have now fixed.

Getting this right would mean, for example, that the nastiness that
is text/x-server-parsed-html3 would be solved; the property of a file
that it is a server-parsed file would be determined seperately from the
html version of the file.

So what we need is a mapping from file extension to handler.


View raw message