Bob Ionescu schrieb:
2009/1/12 Michael Ludwig <mlu@xxxxxxxxxxxxx>:Bob Ionescu schrieb:http://httpd.apache.org/docs/2.2/sections.html#merginThanks. 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-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|