|
Home > Archive > Apache Mod-Python > December 2005 > input/output filters and .htaccess
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
input/output filters and .htaccess
|
|
| Graham Dumpleton 2005-12-20, 7:56 am |
| Anyone know if there are any technical reasons why input/output filters
as they exist at the moment, applying only to body content and not
headers, can not be specified in a .htaccess files?
Specifically, the SetInputFilter, SetOutputFilter, AddInputFilter and
AddOutputFilter directives of Apache can be specified in either main
server configuration or .htaccess files, yet the PythonInputFilter and
PythonOutputFilter directives are only allowed to be specified in the
main server configuration.
This is because mod_python.c contains:
AP_INIT_TAKE12(
"PythonInputFilter", directive_PythonInputFilter, NULL,
RSRC_CONF|ACCESS_CONF,
"Python input filter."),
AP_INIT_TAKE12(
"PythonOutputFilter", directive_PythonOutputFilter, NULL,
RSRC_CONF|ACCESS_CONF,
"Python output filter."),
If however I change it to:
AP_INIT_TAKE12(
"PythonInputFilter", directive_PythonInputFilter, NULL, OR_ALL,
"Python input filter."),
AP_INIT_TAKE12(
"PythonOutputFilter", directive_PythonOutputFilter, NULL,
OR_ALL,
"Python output filter."),
it is then possible to use the mod_python directives in a .htaccess
file.
Running the code this way appears to work for both input and output
filters
when specified in the .htaccess file without problems.
So, does anyone know why this might be a bad idea? I can't really think
of
any reasons why it shouldn't be okay. If there is some confirmation that
it all sounds reasonable, I'll create a JIRA issue for it to be a future
enhancement.
Graham
| |
| Jorey Bump 2005-12-20, 5:47 pm |
| Graham Dumpleton wrote:
> Anyone know if there are any technical reasons why input/output filters
> as they exist at the moment, applying only to body content and not
> headers, can not be specified in a .htaccess files?
>
> Specifically, the SetInputFilter, SetOutputFilter, AddInputFilter and
> AddOutputFilter directives of Apache can be specified in either main
> server configuration or .htaccess files, yet the PythonInputFilter and
> PythonOutputFilter directives are only allowed to be specified in the
> main server configuration.
>
> This is because mod_python.c contains:
>
> AP_INIT_TAKE12(
> "PythonInputFilter", directive_PythonInputFilter, NULL,
> RSRC_CONF|ACCESS_CONF,
> "Python input filter."),
> AP_INIT_TAKE12(
> "PythonOutputFilter", directive_PythonOutputFilter, NULL,
> RSRC_CONF|ACCESS_CONF,
> "Python output filter."),
>
> If however I change it to:
>
> AP_INIT_TAKE12(
> "PythonInputFilter", directive_PythonInputFilter, NULL, OR_ALL,
> "Python input filter."),
> AP_INIT_TAKE12(
> "PythonOutputFilter", directive_PythonOutputFilter, NULL, OR_ALL,
> "Python output filter."),
>
> it is then possible to use the mod_python directives in a .htaccess file.
>
> Running the code this way appears to work for both input and output filters
> when specified in the .htaccess file without problems.
>
> So, does anyone know why this might be a bad idea? I can't really think of
> any reasons why it shouldn't be okay. If there is some confirmation that
> it all sounds reasonable, I'll create a JIRA issue for it to be a future
> enhancement.
Are there any conflicts when a directive appears in both places? If not,
how do they cascade (does the .htaccess trump the one in the conf file,
is it additive, does it respect virtual host or directory boundaries,
etc...)?
| |
| Gregory (Grisha) Trubetskoy 2005-12-20, 5:47 pm |
|
This sounds like a good idea, but it's probably better to push this off to
3.3 just to veer on the side of caution.
My $0.02
Grisha
On Tue, 20 Dec 2005, Graham Dumpleton wrote:
> Anyone know if there are any technical reasons why input/output filters
> as they exist at the moment, applying only to body content and not
> headers, can not be specified in a .htaccess files?
>
> Specifically, the SetInputFilter, SetOutputFilter, AddInputFilter and
> AddOutputFilter directives of Apache can be specified in either main
> server configuration or .htaccess files, yet the PythonInputFilter and
> PythonOutputFilter directives are only allowed to be specified in the
> main server configuration.
>
> This is because mod_python.c contains:
>
> AP_INIT_TAKE12(
> "PythonInputFilter", directive_PythonInputFilter, NULL,
> RSRC_CONF|ACCESS_CONF,
> "Python input filter."),
> AP_INIT_TAKE12(
> "PythonOutputFilter", directive_PythonOutputFilter, NULL,
> RSRC_CONF|ACCESS_CONF,
> "Python output filter."),
>
> If however I change it to:
>
> AP_INIT_TAKE12(
> "PythonInputFilter", directive_PythonInputFilter, NULL, OR_ALL,
> "Python input filter."),
> AP_INIT_TAKE12(
> "PythonOutputFilter", directive_PythonOutputFilter, NULL, OR_ALL,
> "Python output filter."),
>
> it is then possible to use the mod_python directives in a .htaccess file.
>
> Running the code this way appears to work for both input and output filters
> when specified in the .htaccess file without problems.
>
> So, does anyone know why this might be a bad idea? I can't really think of
> any reasons why it shouldn't be okay. If there is some confirmation that
> it all sounds reasonable, I'll create a JIRA issue for it to be a future
> enhancement.
>
> Graham
>
| |
| Graham Dumpleton 2005-12-20, 8:46 pm |
| Jorey Bump wrote ..
> Graham Dumpleton wrote:
>
> Are there any conflicts when a directive appears in both places? If not,
> how do they cascade (does the .htaccess trump the one in the conf file,
> is it additive, does it respect virtual host or directory boundaries,
> etc...)?
It seems to behave as directives would normally behave. That is, a directive
which sets a value will see that which is more specific, ie., defined in a
..htaccess file, override one set in the server configuration. Thus:
# server configuration
PythonOutputFilter uppercase UPPERCASE
SetOutputFilter UPPERCASE
# .htaccess
PythonOutputFilter lowercase LOWERCASE
SetOutputFilter LOWERCASE
Output will be sent through Python lowercase::outputfilter() only.
With filters actually being an indirect name, late binding will occur.
# server configuration (deliberate mistake follows)
PythonOutputFilter lowercase UPPERCASE
SetOutputFilter UPPERCASE
# .htaccess
PythonOutputFilter uppercase UPPERCASE
Output will be sent through Python uppercase::outputfilter()
only. Ie., naming of filter in .htaccess file takes precedence even
though relationships initially created in server configuration file.
In a .htaccess file, you could chain filters defined in different contexts.
SetOutputFilter LOWERCASE;UPPERCASE
Same sort of thing when AddOutputFilter is used.
Graham
| |
| Graham Dumpleton 2005-12-21, 2:46 am |
| Grisha wrote ..
>
> This sounds like a good idea, but it's probably better to push this off
> to
> 3.3 just to veer on the side of caution.
>
> My $0.02
>
> Grisha
Grisha, do you remember why the following warning is present in
directive_PythonInputFilter() and directive_PythonOutputFilter() of
"mod_python.c".
/* register the filter NOTE - this only works so long as the
directive is only allowed in the main config. For .htaccess we
would have to make sure not to duplicate this */
Having input/output filters be able to be specified in .htaccess
must have been considered, but there must have been some issue
with it that prevented it being done at the time.
Also, can you think of any reason why it wouldn't be reasonable
to have support for a mod_python handler being able to register
an output filter to be applied to the current request? Ie., as long
as the output filter is registered prior to the first output from the
handler, the actual output from the handler would be sent through
the filter registered from the handler itself.
Have been thinking about how practical it would be to do things
like have a handler output HTML with tags embedded which are
understood by mod_include (server side includes), and for the
handler before it output the HTML do the equivalent of:
SetOutputFilter INCLUDES
The tags in the HTML could be stuff like "#include virtual" which
would then cause Apache to internally direct sub requests against
other mod_python handlers or static files which include stuff like
common page layouts etc.
Anyway, just toying with ideas.
Graham
[vbcol=seagreen]
> On Tue, 20 Dec 2005, Graham Dumpleton wrote:
>
> of
| |
| Graham Dumpleton 2005-12-21, 7:47 am |
|
On 21/12/2005, at 3:32 PM, Graham Dumpleton wrote:
> Grisha wrote ..
>
> Grisha, do you remember why the following warning is present in
> directive_PythonInputFilter() and directive_PythonOutputFilter() of
> "mod_python.c".
>
> /* register the filter NOTE - this only works so long as the
> directive is only allowed in the main config. For .htaccess we
> would have to make sure not to duplicate this */
>
> Having input/output filters be able to be specified in .htaccess
> must have been considered, but there must have been some issue
> with it that prevented it being done at the time.
Hmmm, looks like it will not be able to be done after all. This is
because registration of a filter by name is done at server scope.
Thus, if done from a .htaccess file in one directory, it will then
be visible in other scopes. The continual registration of the
filter each time a request hits that directory will also cause a
growing use of memory from the server pool (I think). Pity.
I wander though whether one could register a single global hook into
mod_python for filters automatically, and then for configuration of
filters to be managed within mod_python somehow. Anyway, could be an
interesting area for future exploration. Will be interesting to see
how mod_perl might deal with being able to specify filters at .htaccess
level.
Graham
| |
| Gregory (Grisha) Trubetskoy 2005-12-21, 5:47 pm |
|
On Tue, 20 Dec 2005, Graham Dumpleton wrote:
> Grisha, do you remember why the following warning is present in
> directive_PythonInputFilter() and directive_PythonOutputFilter() of
> "mod_python.c".
>
> /* register the filter NOTE - this only works so long as the
> directive is only allowed in the main config. For .htaccess we
> would have to make sure not to duplicate this */
>
> Having input/output filters be able to be specified in .htaccess
> must have been considered, but there must have been some issue
> with it that prevented it being done at the time.
I think it was because if specified in .htaccess, that code would be
executed for every request and something would need to be done to make
sure ap_register_input_filter() is only called once. I don't remember the
intricate details at this point, and it's possible that this warning is
unnecessary either because I didn't understand something or perhaps the
way Apache works has changed. In any event, I'd do some careful
investigating before disregarding that NOTE 
Grisha
| |
| Gregory (Grisha) Trubetskoy 2005-12-21, 5:47 pm |
|
On Wed, 21 Dec 2005, Graham Dumpleton wrote:
>
> Hmmm, looks like it will not be able to be done after all. This is
> because registration of a filter by name is done at server scope.
> Thus, if done from a .htaccess file in one directory, it will then
> be visible in other scopes. The continual registration of the
> filter each time a request hits that directory will also cause a
> growing use of memory from the server pool (I think). Pity.
This may be something you could clarify on the httpd-devel or apr-devel
lists, may be we're missing something in how it was intended to work.
Grisha
|
|
|
|
|