Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Stefan Fritsch <sf@sfritsch.de>
To: dev@httpd.apache.org
Subject: Revisiting the pre_htaccess hook
Date: Sun, 9 Jun 2013 11:57:54 +0200
User-Agent: KMail/1.13.7 (Linux/3.9-1-amd64; KDE/4.8.4; x86_64; ; )
Cc: "Steinar H. Gunderson" <sgunderson@bigfoot.com>,
 Jeff Trawick <trawick@gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201306091157.55040.sf@sfritsch.de>

Hi,

first of all, sorry that it took me so long to review at this.

The current pre_access hook is executed before opening the htaccess 
and then can abort the request with a HTTP error code.

Wouldn't a hook for opening the htaccess file make more sense because 
it would have more possible use cases? Then modules could use this 
hook to find htaccess files somewhere else, generate/extend/filter 
them on the fly, etc. For example:

apr_status_t  ap_run_open_htaccess(request_rec *r, ap_configfile_t *f, 
const char **full_name, const char *dirname, const char *accessname);

The hook would then build full_name (used later for error logging) 
from dirname and accessname and open it with ap_pcfg_openfile().

Downside would be that the hook cannot provide an arbitrary HTTP 
status code. Only no error and FORBIDDEN. Would that be a problem?

We could add an additional int *request_status parameter, too, though.
Or put the error logging/generating of FORBIDDEN into core's 
open_htaccess hook function and make the hook return HTTP status and 
not apr_status_t.

What do you think?

Cheers,
Stefan