All of the changes I'd like to introduce below impact one another, and
are based on several basic premises;


  1. A sub_req_lookup() caller (of any flavor) should be able to make
     heads or tails of the request based on the processing that occurs
     within ap_process_request_internal().

  2. No handler should die on known 'stuff', e.g. headers, etc, when those
     decisions can be made upfront, during the ap_process_request_internal()
     cycle.  A sub_req call can then choose some alternate resource (such as 
     going on to the next entry in the list of DirectoryIndex documents).  
     Dying for reasons we, couldn't determine up-front, such as mis-submitted 
     POST data, remains always acceptable.

  3. Namespace polution is evil.  Ergo, any module should reject requests
     for a document with path_info if it doesn't address the name space
     passed in path_info for the request.

This leads to several individual patches that I'm writing.

. My mod_dir patch which performs the entire internal handling of dirs within
  the fixup hook.  It has an associated patch to restore autoindexes' correct
  behavior {posted 12/2, Message-ID: <021e01c17bab$a9d076c0$93c0b0d0@v505>}

. Patch in HOOK_LAST of ap_run_fixups; punt the *handler to core if the thing is
  a file, and the proper path_info conditions exist, and punt no-file to NOTFOUND 
  and no-handler cases to 500 misconfigured.

. Hooks are _not_ the fastest things in the world, especially with the strcmps
  around ->handler going on.  If we resolve the ->handler up front, why not
  provide a ->handler_fn member that skips the entire handler() hook walk?

. Add DefaultHandler [AcceptPost|RejectPost] [AcceptPathInfo|RejectPathInfo]
  The default to both is, Reject.  This setting is noted, but not acted upon, 
  until we hit the HOOK_LAST of fixups.

. php and others may then toggle the setting for Post or PathInfo in their setup
  hooks, so they can superceed the user .conf setting or the defaults.

. move ap_run_insert_filter to the run_subreq code, so we get that possibly
  expensive hook into the content.  Since it can't fail, it doesn't need to sit
  up in the lookup logic.

Comments?

Bill

Reply via email to