mod_ext_filter and HTTP status codes
Is there any way to have an external program (called via mod_ext_filter) tell the server to return a different status code (other than 200). Specifically, I want to be able to set a 500 error. Also, a nice to have would be a way to set other HTTP headers (like Last-Modified). Conceptually, I'm not even sure how that would work... maybe via the ext program's exit codes? Any ideas would be appreciated. TIA Craig
mod_ext_filter and last-modified header
It looks like mod_ext_filter sets the last-modified http header based on the mod time of the *filter* file and not the actual file represented by the URL. eg. the following filter is configured in httpd.conf ExtFilterDefine filter-name mode=output intype=text/html outtype=text/html \ cmd=/web_home/filters/filter.pl Directory /web_home/htdocs SetOutputFilter filter-name [etc...] now, if you try to get the following url: http://server/file.html the Last-Modified HTTP header seems to be set based on the timestamp on /web_home/filters/filter.pl and NOT on /web_home/htdocs/file.html i was hoping that this would be an easy fix for someone a lot more familiar with the code. i do understand that this may change the current behavior of existing apps that use mod_ext_filter... so, comments are welcomed... tia! craig
Re: mod_ext_filter and last-modified header
Quoting Geoffrey Young ([EMAIL PROTECTED]): Craig Sebenik wrote: It looks like mod_ext_filter sets the last-modified http header based on the mod time of the *filter* file and not the actual file represented by the URL. the Last-Modified HTTP header seems to be set based on the timestamp on /web_home/filters/filter.pl and NOT on /web_home/htdocs/file.html I would hope it would be the newer of both, since both contribute to the freshness of the content, which is what is important. if you touch file.html do you get the newer timestamp? my mistake. it looks like it works just the opposite of what i said. if i change the *code*, and NOT the file, then the last-modified is unchanged. i agree, it should be the newer of both. (fyi, the machines are in the pacific time zone.) ll file.html -rw-rw-r-- 1 craighttp2898 Apr 13 19:03 file.html ll ../../public/filters/filter.pl -rwxrwxr-x 1 craighttp 368 Apr 9 14:39 ../../public/filters/filter.pl* HEAD server/form11/file.html 200 OK Cache-Control: max-age=0, public, must-revalidate Connection: close Date: Wed, 14 Apr 2004 02:07:53 GMT Accept-Ranges: bytes ETag: 13ec08a-b52-6312b4c0 Server: Apache/2.0.39 (Unix) Content-Length: 3178 Content-Type: text/html; charset=ISO-8859-1 Expires: Wed, 14 Apr 2004 02:07:53 GMT Last-Modified: Wed, 14 Apr 2004 02:03:39 GMT Client-Date: Wed, 14 Apr 2004 02:04:22 GMT Client-Response-Num: 1 touch ../../public/filters/filter.pl ll file.html -rw-rw-r-- 1 craighttp2898 Apr 13 19:03 file.html ll ../../public/filters/filter.pl -rwxrwxr-x 1 craighttp 368 Apr 13 19:08 ../../public/filters/filter.pl* HEAD server/form11/file.html 200 OK Cache-Control: max-age=0, public, must-revalidate Connection: close Date: Wed, 14 Apr 2004 02:08:28 GMT Accept-Ranges: bytes ETag: 13ec08a-b52-6312b4c0 Server: Apache/2.0.39 (Unix) Content-Length: 3178 Content-Type: text/html; charset=ISO-8859-1 Expires: Wed, 14 Apr 2004 02:08:28 GMT Last-Modified: Wed, 14 Apr 2004 02:03:39 GMT Client-Date: Wed, 14 Apr 2004 02:05:00 GMT Client-Response-Num: 1 touch file.html ll file.html -rw-rw-r-- 1 craighttp2898 Apr 13 19:15 file.html ll ../../public/filters/filter.pl -rwxrwxr-x 1 craighttp 368 Apr 13 19:08 ../../public/filters/filter.pl* HEAD craig-www/form11/file.html 200 OK Cache-Control: max-age=0, public, must-revalidate Connection: close Date: Wed, 14 Apr 2004 02:15:11 GMT Accept-Ranges: bytes ETag: 13ec08a-b52-8c057e80 Server: Apache/2.0.39 (Unix) Content-Length: 3178 Content-Type: text/html; charset=ISO-8859-1 Expires: Wed, 14 Apr 2004 02:15:11 GMT Last-Modified: Wed, 14 Apr 2004 02:15:06 GMT Client-Date: Wed, 14 Apr 2004 02:11:43 GMT Client-Response-Num: 1
HTTP_REFERER in mod_ext_filter
Currently, mod_ext_filter doesn't seem to grab all of the environment variables. One that's notably missing is HTTP_REFERER. But, I can't figure out where this env variable is set. I searched thru the source files (*.c and *.h) and the only reference I found was in modules/ssl/ssl_engine_vars.c and modules/mappers/mod_rewrite.c. I was hoping someone could point me to how/where this env var is set. I am pretty new to the apace src, so I apologize if this is an obvious (aka stupid : ) question. TIA Craig
Re: environment in mod_ext_filter
Quoting Jeff Trawick ([EMAIL PROTECTED]): Craig Sebenik [EMAIL PROTECTED] writes: Is there a reason why the environment is null? probably because I'm a moron :) :) *Probably*??? You're not sure? :) Am I missing something? Is there a reason I shouldn't submit this patch? no, no I put it in as a bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10925 The dev guidelines say that patches can be submitted either via an email (to this list) or via the bug database. But, it doesn't say which is preferred... I guess different people would have different preferences... Anyway, it's there... I could send it to the list also, if you prefer. You'll notice that I put in a call to ap_add_cgi_vars, which may be a little excessive (or down right wrong). So, that is up for discussion. Craig
environment in mod_ext_filter
Hi, In modules/experimental/mod_ext_filter.c there's the following: rc = apr_proc_create(ctx-proc, ctx-filter-command, (const char * const *)ctx-filter-args, NULL, /* environment */ ctx-procattr, ctx-p); Is there a reason why the environment is null? I was able to hack in the env in a few simples lines. Am I missing something? Is there a reason I shouldn't submit this patch? Thanx, Craig
