> On Tue, 27 Mar 2001, Bill Stoddard wrote:
>
> > > Isn't this a huge security whole? You have basically allowed somebody
to
> > > server information off a web server without even checking for
> > > authentication.
> >
> > It is up to the module author using the quick_handler hook to do the right
> > thing. Consider Mike Abbott's quick shortcut cache: nothing is placed in
the
> > cache unless it meets certain restrictions (not dynamically generated, not
> > access protected, not negotiated, etc.). In the QSK, if a request comes in
and
> > it meets certain criterion and a search of the URI cache yields a hit,
then by
> > definition it is okay to serve up the content. I am working on a
variation of
> > the QSK for use by this hook.
>
> IMO, this is the wrong way to cache things. You are asking for trouble.
> The better way to cache, is to determine which hooks were actually used by
> a given request, and only call those hooks that are required. That way,
> the cache is useful for all requests, and we retain security.
The entire point of the quick handler hook is to bypass all the other hooks.
Sure the hook can be abused, but it is not unique in this regard. Any of the
hooks can be abused.
>
> So, basically we have just implemented an entire hook for one use case?
It is a very specialized hook. The alternative is to add a preprocessor macro
to add a code path to call a hardcoded function (e.g., qsc_handle_request())
like in Mike Abbott's original patch. Adding the hard coded function is a
hack, imho and we have a really nifty tool to cover just this sort of thing,
the hooks API.
> What does this do to requests that don't use this hook.
First, a module must register interest in this hook. If no modules register
interest in the hook, then the call to ap_run_quick_handler() will return
DECLINED. If a quick handler is installed, the handler will either return OK
indicating that it handled the request or DECLINED.
>
> > The other use I can envision is to delegate authority to serve request out
of
> > a particular URI space (say URI = /www/servlets/*) to a quick_handler
> > implemented by a module that intercepts requests for a servlet engine
(e.g.
> > Tomcat). The servlet engines that I am aware of (including Tomcat) have
their
> > own access control and do not use Apache's access control. Using the
> > quick_handler, it would be simple to quickly route dynamic requests
generated
> > by servlets to Tomcat but serve the static content out of a cache or the
file
> > system.
>
> Servlet engines allow one or the other. Most servlet engines will let you
> use Apache's auth stuff if you want to. This hook also bypasses the
> translate_name hook and fixups, so I am relatively sure that just sending
> data to the servlet engine is a bad idea.
>
And if you -know- you don't want to rely on any of the Apache services for
your dynamic content (except thread dispatching, etc.), you are still stuck
with the overhead of the calls.
> > It would almost certainly be a serious mistake to try to serve content out
> > directly out of the file system from a quick_handler.
>
> That bothers me. Saying that we have a way to send data that should
> not be used off the FS seems a bit hokey to me.
>
It is not hokey. Why go through the overhead of translating a URI to a file
name when the content you are serving does not necessarily correspond to a
file? In the quick cache case, you can map a URI to a cache entry that
corresponds to that URI. You don;t need to know where that data originates. It
could be from a file, a database, put there by God, whatever.
Bill
