Re: [PATCH] PR 17629 and all that
On 06/08/2010 02:37 PM, Joe Orton wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=17629 Here's an attempt at fixing the dreaded PR 17629. This is a bug in the handling of the output filter chain at the point where an internal redirect is applied to a subrequest. Complications: a) a subrequest's filter chain may start at an arbitrary point in r-main's filter chain -- for an SSI include, the output from the include must continue from the next filter along from the INCLUDES filter Could this in some way be related to the bug I filed a while ago where the SSI output filter mangles the QUERY_STRING variable by replacing it with the query string used in the last include directive? https://issues.apache.org/bugzilla/show_bug.cgi?id=49043 This behavior changed between 1.3 and 2.x and my uninformed guess is that this is probably a scoping issue that happened when SSI was turned into a filter (i.e. before the QUERY_STRING was only modified for each subrequest but in a filter context the changed QUERY_STRING string no basically is used for all following data). Regards, Dennis
Re: C as config
On 06/05/2010 12:51 AM, Igor Galić wrote:
Not a terribly interesting read, but we are seriously considering just
using
straight C with some helper functions and macros as the config for
one of
our projects.
And, for the record I was wrong in the past - yes, async is the
answer...
I've been a longtime critic, though I haven't taken it to the list,
of the httpd Configuration Language. For other reasons than performance
though -- mostly sane defaults, but that's an entirely different topic.
BUT: I did my share of support on nginx - even though I don't know it
well enough and nginx, like varnish, uses a C-like syntax for the configs.
I for one, would welcome such a possibility.
The nginx syntax may look C-like but it really isn't at all. For one thing
it's declarative and then you have all kinds of weird behaviors with
variables and control structures that make no sense if you're coming from
C-like angle.
I think what Brian is really aiming for is an actual procedural
configuration that basically gets executed when a request arrives.
Something along the line of:
function handleReq( req ) {
if( req.domain ~ www.test.com ) {
documentRoot(/sites/test);
customLog(/var/log/test.log,combined);
return true;
}
}
Not sure if that would do much for Apache but with nginx sometimes I really
would like to have something like this.
Regards,
Dennis
mod_include clobbering QUERY_STRING
Hi,
It looks like there is a problem in the handling of virtual includes with
Apaches SSI filter.
Take the following code:
htmlbody
!--#echo var=QUERY_STRING--
!--#include virtual=/ssi2.php?abc=1--
!--#echo var=QUERY_STRING--
/body/html
If this is called with the query string (url)?test=1 then the first echo
will print test=1 as expected but the second one will output abc=1.
Apparently the include in the middle completely obliterates the original
query string making it unusable for subsequent includes.
That's a major problem as soon as you use more than one SSI include with
QUERY_STRING in your pages.
(I'm seeing this with the httpd from the latest Centos as well as the newer
httpd 2.2.15 from Fedora using the SSI output filter)
If I remove the following code from mod_include's output filter:
...
if (r-args) {
char *arg_copy = apr_pstrdup(r-pool, r-args);
apr_table_setn(r-subprocess_env, QUERY_STRING, r-args);
ap_unescape_url(arg_copy);
apr_table_setn(r-subprocess_env, QUERY_STRING_UNESCAPED,
ap_escape_shell_cmd(r-pool, arg_copy));
}
...
The QUERY STRING variable no longer gets changed and the called ssi2.php
still gets the abc=1 as query string but I'm sure there is a reason for
this code to be there.
Does anyone know what is going on here?
(I filed a bug for this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49043 )
Regards,
Dennis
SSI bug?
Hi, It looks like Apache kills the contents of the QUERY_STRING SSI variable when using virtual includes: htmlbody !--#echo var=QUERY_STRING-- !--#include virtual=/ssi2.php?abc=1-- !--#echo var=QUERY_STRING-- /body/html When called with ?test=1 the first echo will correctly output test=1 but the second will output abc=1 instead. Is this expected behaviour? Regards, Dennis
Re: Linking in libraries to Apache Module
Have you tried ldd path-to-compiled-module? That could also give you a hint if anything is fishy with the library paths/dependencies. Regards, Dennis On 12/08/2009 01:07 AM, Devin Ceartas wrote: hm. -rpath doesn't seem to be an accepted flag in the apxs included with the latest OpenBSD -- devin On Dec 7, 2009, at 6:56 PM, Joe Lewis wrote: Devin Ceartas wrote: The logic of my SQLite code works if I compile it as a stand-alone executable. My mod_hello.c compiles and loads/works fine without the SQLite code Combining the two, the module compiles and is installed, but the apache process dies immediately (core dump) every time it is loaded. Stripping out all the SQLite code and simply linking against SQLite causes this problem. In other words, with the same code: apxs -cia -L/usr/local/lib -I/home/devin mod_hello.c /* Works Fine, prints hello world */ apxs -cia -L/usr/local/lib -I/home/devin -lsqlite3 mod_hello.c /* compiles but dies on apache load */ The platform is OpenBSD 4.6 with the platform's version of Apache 1.3 and SQLite 3.6.20 downloaded from the SQLite site and compiled from source Since I'm just getting started with C apache modules, I assume I'm missing something basic. If using a Linux-based system, I'd suggest ensuring that ld.so.conf is setup to point to the directory or that the compile has the runtime path for the sqlite library. For example, I have added -rpath /usr/local/lib -rpath /usr/local/lib/mysql to my -L parameters for apxs to load mySQL external modules dynamically in the past. Linux-based systems also have an strace command that may be used to figure out what libraries are missing. -- Joe Lewis Chief Nerd SILVERHAWK http://www.silverhawk.net/ (801) 660-1900 /Rights that do not flow directly from duty well performed are not worth having. --Mohandas K. Gandhi/
Excluding SSI content from filtering
Hi, I wrote a module that adds a header and a footer to html output and that works pretty well. The problem ist that once i add a !--#include virtual=/ssi/... -- directive the content included also gets that header and footer applied. Is there a way to prevent the header/footer filter from dealing with such a SSI sub-request so that it only applied to the final webpage? Regards, Dennis
Re: Excluding SSI content from filtering
Works perfectly! Thanks!
Regards,
Dennis
On 07/13/2009 08:51 PM, Ronald Park wrote:
I believe you should wrap your header/footer inserter inside an
if (!r-main ) {
...
}
block. So only the 'main' request is wrapped but not any subrequests.
Ron
On Mon, 2009-07-13 at 20:45 +0200, Dennis J. wrote:
Hi,
I wrote a module that adds a header and a footer to html output and that
works pretty well. The problem ist that once i add a !--#include
virtual=/ssi/... -- directive the content included also gets that
header and footer applied. Is there a way to prevent the header/footer
filter from dealing with such a SSI sub-request so that it only applied to
the final webpage?
Regards,
Dennis
Re: apr_palloc return value?
On 04/08/2009 10:13 PM, Nick Kew wrote: On Wed, 8 Apr 2009 22:07:55 +0300 Juha Korhonenmahtav...@gmail.com wrote: Hi, when I use apr_palloc function to allocate memory, should I check the return value to make sure that I really got some memory? Yes. Sort-of. That is to say, yes you should, but it's common practice to omit the test, on the dubious grounds that if pool allocation fails, then your error handling is pretty-much going to fail for the same reason so it's pointless. Why? If I try to allocate 1GB of memory and that fails why is error handling pretty-much going to fail after that? There still could be 500MB of ram free which would probably be more than enough to handle such an error or is there anything fundamentally different compared to to a malloc all (other than that it uses a pool)? Regards, Dennis
preventing filter from running for server side includes
Hi, Im trying to develop a simple filter that adds a header and a footer to a page. My problem is that the page can also contain server side includes and I obviously only want to add the header and footer on the outer part of the document. If I don't allow server side includes things work out fine: In the filter I check if f-ctx is set. If it isn't I initialize it and push out the header. Then I pass through the response data and when I hit the EOS bucket I push out the footer. That works as it should. Once I add the server side includes into the mix I thought I simply check f-r-main is this is a sub-request and don't output the header and footer and simply pass through the data. That actually seems to work too. My problem is that according to the debug log output there is an additional sub-request happening and I don't really understand where that is coming from. This is test.html: html body test !--#include virtual=test2.html -- /body /html Simple enough. test2.html only contains the word inc. When I request test.html I get the following output in the debug log: mod_mymodule: filter called (/test.html) mod_mymodule: filter: init f-ctx (/test.html) mod_mymodule: insert header (/test.html) mod_mymodule: filter: regular bucket found (/test.html) mod_mymodule: leaving filter (/test.html) mod_mymodule: filter called (/test2.html) mod_mymodule: filter: init f-ctx (/test2.html) mod_mymodule: skipping header (/test2.html) mod_mymodule: filter: regular bucket found (/test2.html) mod_mymodule: filter called (/test.html) mod_mymodule: filter: init f-ctx (/test.html) mod_mymodule: insert header (/test.html) mod_mymodule: filter: regular bucket found (/test.html) mod_mymodule: leaving filter (/test.html) mod_mymodule: filter: EOS bucket found (/test2.html) mod_mymodule: skipping footer (/test2.html) mod_mymodule: leaving filter (/test2.html) mod_mymodule: filter called (/test.html) mod_mymodule: filter: f-ctx already initialized mod_mymodule: filter: regular bucket found (/test.html) mod_mymodule: filter: EOS bucket found (/test.html) mod_mymodule: insert footer (/test.html) mod_mymodule: leaving filter (/test.html) I indented the output to make the call structure more visible. I get the first and second level and there everything seems to work out fine. Header and footer get inserted on level 1 and the are skipped for level 2 since it's a sub-request. But where does the third invocation of the filter for test.html come from? Alternatively how can I make sure that header and footer are only output once for the overall request? Does anyone have an idea for a better strategy? Regards, Dennis
