Bob Ionescu schrieb:
2009/1/12 Michael Ludwig <m...@as-guides.com>:
Bob Ionescu schrieb:
http://httpd.apache.org/docs/2.2/sections.html#mergin
Thanks. This helps a bit. But I still don't quite understand the
meaning of "be applied" and "be evaluated" in this section. Does this
refer to the merging,
Yes, merging of sections.
so that late-comers override earlier directives?
In the described order (there can be exceptions when modules bypass
the directory and file walk).
Thanks for confirming this.
There's a merging within that sections, too, of course (e.g.
<Directoty /foo> overrides <Directory /> if the first path segment
is foo).
Yes.
No, just the filename you gave in DirctoryIndex. It won't be served
due to your Handler setting but acts as a dummy for the requirement
of mod_dir (existing file).
I get it now, thanks to your explanation further down this mail.
DirectoryIndex causes a filesystem lookup to happen. If successful, the
request URL is rewritten accordingly, but not yet served, because Apache
handles requests in different phases, and DirectoryIndex is not itself a
content handler; as a fixup handler, it only prepares the stage.
In the subsequent content handling phase, most DirectoryIndex scenarios
will simply cause the file to be served, because that likely was your
intention when configuring the DirectoryIndex. In this case, however, we
set up a dummy file, and our intention is not for the file to be served,
but for the request to be rewritten accordingly so that in the content
handling phase our <Location> handler kicks in.
Quite subtle, if you're not aware of the underlying processing model.
That's surprising. I would have expected the dummy file to be served.
You set a specific handler and unless all registered handlers are
saying "no, I don't take this request" the default handler isn't
invoked.
http://httpd.apache.org/docs/2.2/mod/mod_dir.html#directoryindex
Given that an existing file has been found, why not serve it up
straight away? Why continue looking for a handler when the file is
found on disk, and *not* look for a handler when no file is found?
Maybe that's just me, but I find this behaviour a little
counter-intuitive. But hey, if it works.
That's a bit complicated to describe. Very briefly - Apache uses
hooks, e.g. those which perform uri-to-filename translation (mapping
the request to the filsystem), access check, auth check, fixup hook
and a handler hook to name a few. [1] should give you an idea how the
processing works. A module registers hooks for its functions. mod_dir
acts in the fixup hook phase only.
Okay: "The fixups phase is happening just before the content handling
phase. It gives the last chance to do things before the response is
generated."
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlFixupHandler
(This is mod_perl documentation - couldn't find an equivalent document
for straight Apache.)
A an uri-based subrequest will run for /indexfile. If the subreq.
returned OK and mod_dir's additional check for an existing file
passes, the results from the subrequest are copied to the main request
(basically). Everything else after mod_dir's fixup hook will look at
r->filename /path/to/indexfile and r->uri /indexfile.
When the handler hook is reached, all registered handlers are
processed until one returned OK "I took it" (after processing). The
handler hook is a run_first hook, which means if one handler returned
OK the handlers after this one won't run anymore. The default handler
which should serve your plain html file runs very last in the handler
hook phase. If you set a handler and your handler takes the request,
the default handler isn't reached, i.e. the plain html file wouldn't
be served (assuming that your handler doesn't do that).
Awesome. Thanks a million for this thorough explanation!
Michael Ludwig
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
" from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
