Outch, a few problems for 2.0/2.2
1. We've really got to die on ./configure, not make, when we are asked to --enable-ldap where apr-util wasn't built with ldap. That's bogus; ./configure should describe anticipated problems, not later on. 2. Something's wrong with detection of ssl, even when I explicitly asked for /usr/local/ssl it's picking up /usr/sfw and I'm not yet sure why. (Both paths are passed, outch!) 3. We currently abspath the APR_UTIL_LIBS entry for /path-to/srclib/apr-util/xml/expat/lib/libexpat.la, but that seriously breaks my AIX vpath builds. I can guess we are trying to avoid picking up libexpat elsewhere in the -L list, but there's gotta be a better way for ordering this, and make it consistent 4. The libtool configs are pretty hokey. apr-util properly dereferences the apr libtool, why don't we do the same on our builtin expat? 5. Also hitting another abspath issue when trying to build apr-util and it's going for the absolute apr.la, working on that when I go back to AIX tomorrow. Finally vpath + symlink builds were broken, there is a set of patches over on http://people.apache.org/~wrowe/ named fixbuild-n.n.patch where -n.n is -2.0 & -0.9, -2.2 & -1.2, and -2.3 & 1.3 for the corresponding httpd and apr-util versions. The patches; * ensure we don't look for srclib/apr*** directories, but simply the file contained within. * avoid looking from apr-util to ../apr, since on symlinked environments in solaris this can be erronious. * ensure we don't bomb on vpath builds looking for .h files in both the source and vpath target trees (because they don't exist in both). * properly check if we are vpath'ing for apr-util/xml/expat, creating that directory in the vpath target, and introduce the syntax --with-expat=builtin to resolve the ambiguity that vpath builds of the builtin expat introduces. * never configure apr-iconv from apr-util. Since we won't configure apr from apr-util this was inconsistent. Comments on the proposed patches so far?
Re: Accessing POST request body from a module
Hello,
With something like that :
while (ap_get_brigade(r->input_filters, brigade, AP_MODE_READBYTES,
APR_BLOCK_READ, len) == APR_SUCCESS) {
apr_brigade_flatten(brigade, buf, &len);
apr_brigade_cleanup(brigade);
tlen += len;
if (tlen == count_bytes || !len) {
break;
}
buf += len;
len = count_bytes - tlen;
}
- Original Message -
From: "Phil Endecott" <[EMAIL PROTECTED]>
To:
Sent: Thursday, February 02, 2006 11:45 PM
Subject: Accessing POST request body from a module
Dear All,
I am porting some CGI code to run as a module. It is all pretty
straightforward, except that I can't work out how to get at a POST
request's body. The CGI code reads from stdin, which doesn't seem to be
the right thing to do in the module. I'm probably missing something
obvious; maybe I'm not searching for the right keywords. Can someone
point me in the right direction?
Many Thanks,
--Phil.
Re: Accessing POST request body from a module
On Thursday 02 February 2006 22:45, Phil Endecott wrote: > [chop] If you had a usable-looking email address. I could reply with exactly what you need, from something that's not currently available on a public mailinglist. -- Nick Kew
Re: svn commit: r374257 - in /httpd/mod_python/trunk: lib/python/mod_python/cache.pytest/test.py
Graham Dumpleton wrote:
Jim Gallacher wrote ..
I'm getting a unit test failure.
FAIL: test_publisher_cache (__main__.PerRequestTestCase)
--
Traceback (most recent call last):
File "test.py", line 1836, in test_publisher_cache
self.fail(
File "/usr/lib/python2.3/unittest.py", line 270, in fail
raise self.failureException, msg
AssertionError: The publisher cache has reloaded a published module even
though it wasn't modified !
Although it's not related to the failure I'd avoid the use of
time.clock() in the test function as the behaviour is different on
Windows and UNIX, which always makes me nervous. I'd prefer a simple
time.time().
It isn't time.time().
I wasn't suggesting time.clock() was the problem, just that I'd prefer
any function we use in the unit tests has identical behaviour on all
platforms, at least to the extent that is possible.
It is because you probably have a prefork/worker MPM.
The test as written will only reliably work for winnt MPM.
Doh! Prefork bites us in the a** yet again. :)
On UNIX boxes
the subsequent requests could be handled by a different child process.
The configuration as to how many servers to start is:
IfModule("prefork.c",
StartServers("3"),
MaxSpareServers("1")),
IfModule("worker.c",
StartServers("2"),
MaxClients("6"),
MinSpareThreads("1"),
MaxSpareThreads("1"),
ThreadsPerChild("3"),
MaxRequestsPerChild("0")),
Does that make sense, or did I miss something.
Yes, that makes sense. Testing it now.
Jim
Re: 3.2.6 or not
To confirm Jim's arithmetic anyway, I say -1 on 3.2.6 as it stands. As to 3.2.7, I say +1, subject to removal of problematic test case as already raised and with us at least confirming tests run OK for version out of SVN prior to packaging. Graham Jim Gallacher wrote .. > According to the Apache rules we need three +1 votes. As there are only > 4 of us voting the two +0 votes are already enough to kill the proposal. > (I should have done the math this morning. ;) ) > > I'll commit Grahams' _conn_read fix and generate the 3.2.7 tarball > shortly. I'm also +1 on releasing 3.2.7 without a restrained testing period. > > Jim > > > Nicolas Lehuen wrote: > > My official vote is eventually -1 for 3.2.6, see the previous > > discussion for why I've changed my mind. > > > > However I'm +1 on releasing 3.2.7 without a restrained testing period, > > not a long one like for 3.2.6. > > > > Regards, > > Nicolas > > > > 2006/2/2, Jim Gallacher <[EMAIL PROTECTED]>: > > > >>I know you said no discussion Grisha, but can I have 2 ballots? ;) > >> > >>-1 If Graham thinks his conn handler fix is good, let's do 3.2.7 today. > >> > >>+1 If Graham is not sure, we release 3.2.6 now as is, and do a 3.2.7 > >>bugfix in the next 4 to 6 weeks after digging into _conn_read issue further. > >> > >>So, I guess that makes my official vote a +0. > >> > >>Over to you Graham. No pressure though. :) > >> > >>Jim > >> > >>(Dang, it makes me feel dirty to waffle on my first offical vote that > way). > >> > >>Gregory (Grisha) Trubetskoy wrote: > >> > >>>OK, I know we've had some votes on this before, but I'd like to put > this > >>>in a separate thread where it's not intermixed with all kinds of other > >>>things. > >>> > >>>This is a vote for the core group. We can release the 3.2.6 tarball > as > >>>is or fix the connection handler bugs (there are two of them - the > >>>buffer pointer and eagain condition Graham tracked down) and release > a > >>>3.2.7 (or 3.2.6.1). The rationale for disregarding those known issues > is > >>>that the connection handler is hardly used by anyone. The rationale > for > >>>NOT disregarding is that we claim this to be a stable release, and given > >>>our slow release cycle, I imagine 3.2.6 will be around for a while. > >>> > >>>Anyhow - *the core group* (you know who you are), if you think 3.2.6 > >>>should be released as is, send in your +1. > >>> > >>>Let's keep this thread strictly a vote, without it turning into a > >>>discussion (we can discuss things in other threads). > >>> > >>>My official vote is +0. > >>> > >>>(To see what this means read http://httpd.apache.org/dev/guidelines.html) > >>> > >>>Grisha > >>> > >> > >> > >
Re: Python 2.2 support
Daniel J. Popowich wrote .. > Graham Dumpleton writes: > > > > On 03/02/2006, at 4:48 AM, Daniel J. Popowich wrote: > > > My gut says any major release of mod_python be based on one > > > major.minor release lower than the currently available python. So, > > > mod_python 3.2 is based on python 2.3; mod_python 3.3 will probably > be > > > based on python 2.4 (because 2.5 will be out by then). > > > > Unfortunately, we are going to be stuck with Python 2.3 for quite a > > while probably. You stand to anger a lot of Mac OS X users, me > > included, if Python 2.4 is required. This is because Apple still > > only ships 2.3.5 even with its latest OS. It is looking to be a year > > before next OS from Apple is out and adopted. > > You can run 2.4 today! That's what Fink is for!!! I know you can get Python 2.4 from fink and there is also MacPython package as well. I and I suspect many others prefer to use what the OS provides rather than load on a whole lot of extra stuff. Many would be ignorant that there are even alternatives. We can't ignore that. Graham
Re: svn commit: r374257 - in /httpd/mod_python/trunk: lib/python/mod_python/cache.pytest/test.py
Jim Gallacher wrote ..
> I'm getting a unit test failure.
>
> FAIL: test_publisher_cache (__main__.PerRequestTestCase)
> --
> Traceback (most recent call last):
>File "test.py", line 1836, in test_publisher_cache
> self.fail(
>File "/usr/lib/python2.3/unittest.py", line 270, in fail
> raise self.failureException, msg
> AssertionError: The publisher cache has reloaded a published module even
> though it wasn't modified !
>
>
> Although it's not related to the failure I'd avoid the use of
> time.clock() in the test function as the behaviour is different on
> Windows and UNIX, which always makes me nervous. I'd prefer a simple
> time.time().
It isn't time.time(). It is because you probably have a prefork/worker MPM.
The test as written will only reliably work for winnt MPM. On UNIX boxes
the subsequent requests could be handled by a different child process.
The configuration as to how many servers to start is:
IfModule("prefork.c",
StartServers("3"),
MaxSpareServers("1")),
IfModule("worker.c",
StartServers("2"),
MaxClients("6"),
MinSpareThreads("1"),
MaxSpareThreads("1"),
ThreadsPerChild("3"),
MaxRequestsPerChild("0")),
Does that make sense, or did I miss something.
Graham
Accessing POST request body from a module
Dear All, I am porting some CGI code to run as a module. It is all pretty straightforward, except that I can't work out how to get at a POST request's body. The CGI code reads from stdin, which doesn't seem to be the right thing to do in the module. I'm probably missing something obvious; maybe I'm not searching for the right keywords. Can someone point me in the right direction? Many Thanks, --Phil.
Re: Python 2.2 support
Graham Dumpleton writes: > > On 03/02/2006, at 4:48 AM, Daniel J. Popowich wrote: > > My gut says any major release of mod_python be based on one > > major.minor release lower than the currently available python. So, > > mod_python 3.2 is based on python 2.3; mod_python 3.3 will probably be > > based on python 2.4 (because 2.5 will be out by then). > > Unfortunately, we are going to be stuck with Python 2.3 for quite a > while probably. You stand to anger a lot of Mac OS X users, me > included, if Python 2.4 is required. This is because Apple still > only ships 2.3.5 even with its latest OS. It is looking to be a year > before next OS from Apple is out and adopted. You can run 2.4 today! That's what Fink is for!!! My last job I was in a Mac shop...first thing I did was find out how to get un-mac-ified opensource tools. Didn't take me long to find fink and have a completely parallel gnu system running side-by-side with OS X. Similar to running cygnus on a winblows box. There...I'm out of the closet...I'm a linux snob. :-) Daniel Popowich --- http://home.comcast.net/~d.popowich/mpservlets/
Re: Win32 Apache and ldap size limit problem.
FYI, I posted a patch to http://issues.apache.org/bugzilla/show_bug.cgi?id=37814 I took the easy route and just added a #if block to util_ldap to set a sizelimit of 2147483647 if the microsoft ldap sdk was in use or otherwise -1 and use this sizelimit define in ldap_search_ext_s calls. Ideally sizelimit could be configureable via a module directive, but since we'll be maintaining our own build with this patch I didn't want to do anything too heavyweight. Andy Andy Wang wrote: I noticed that with OpenLDAP 2.2.x, auth_ldap from apache on windows fails. The actual error ends up being a invalid size limit on the openldap end of things. After doing some research, it looks like the Microsoft SDK defaults the sizelimit to (2^32)-1 (4294967295 or basically an unsigned 32-bit int). OpenLDAP 2.2.x restricts the sizelimit to (2^(32-1)) -1 (2147483647 or a signed 32-bit int). I have no idea how to report this to microsoft, as it's the microsoft SDK that's out of spec. RFC 2251 (http://www.ietf.org/rfc/rfc2251.txt) declares the max of a size limit to be the openldap value. As far as I can tell, none of the other ldap servers care and openldap 2.1.x didn't care either, but unfortunately, 2.2.x does care. Anyone else run into this problem and have any ideas or know how ot report this to MS? I was thinking of filing an Apache bug/enhancement requesting that apache be able to pass a size limit to the ldap query. In theory, you could override this MS SDK problem by explicitly setting the size limit to a proper value, or patch openldap to ignore it. Thanks, Andy
Re: 3.2.6 or not
I know you said no discussion Grisha, but can I have 2 ballots? ;) -1 If Graham thinks his conn handler fix is good, let's do 3.2.7 today. +1 If Graham is not sure, we release 3.2.6 now as is, and do a 3.2.7 bugfix in the next 4 to 6 weeks after digging into _conn_read issue further. So, I guess that makes my official vote a +0. Over to you Graham. No pressure though. :) Jim (Dang, it makes me feel dirty to waffle on my first offical vote that way). Gregory (Grisha) Trubetskoy wrote: OK, I know we've had some votes on this before, but I'd like to put this in a separate thread where it's not intermixed with all kinds of other things. This is a vote for the core group. We can release the 3.2.6 tarball as is or fix the connection handler bugs (there are two of them - the buffer pointer and eagain condition Graham tracked down) and release a 3.2.7 (or 3.2.6.1). The rationale for disregarding those known issues is that the connection handler is hardly used by anyone. The rationale for NOT disregarding is that we claim this to be a stable release, and given our slow release cycle, I imagine 3.2.6 will be around for a while. Anyhow - *the core group* (you know who you are), if you think 3.2.6 should be released as is, send in your +1. Let's keep this thread strictly a vote, without it turning into a discussion (we can discuss things in other threads). My official vote is +0. (To see what this means read http://httpd.apache.org/dev/guidelines.html) Grisha
AW: Apache proxy behaviour...
-Ursprüngliche Nachricht- Von: CASTELLE Thomas . > Anyway, even if the Apache timeout is increased, Firewalls or browsers don't > like idle TCP/IP session either... without speaking of the users ;-) > Regarding my problem, I tried to disable every modules (except mod_proxy of > course), and it still doesn't work... > It seems to confirm what Rüdiger said... In general mod_proxy_http of httpd 2.2.x is prepared for this task, but is does not work because of the EAGAIN problem. mod_proxy_http of httpd 2.0.x is not prepared at all for such things. Regards Rüdiger
module development question
Hi, I have some specific questions concerning a module I would like to write. Or I'd, of course, like to know if something already exists that does the same or similar thing. Please, let me know if there is a more appropriate mailing list to ask this. Basically, the module would, upon receiving a request for a configured uri, fork/exec a process and have Apache abandon any further handling of the request (i.e. close its copy of the socket handle, set conn->aborted=1, return DONE, etc). The child process would inherit the socket handle and continue to run after apache has supposedly finished "handling" the request. It's unlike CGI, in that the process outlives the request and data to/from the fork/exec()-ed process is not filtered through Apache. The end result is that apache is a bit like an xinetd super-daemon for some server peice of a client/server application, but (the good part) the port is "shared" with web traffic too. If this sounds like something someone can deal with answering questions about, let me know and I will ask more specific question on or off (<-- please specify) the mailing list. Thanks, Davy
RE: Apache proxy behaviour...
Well, I think increasing the proxy timeout isn’t a good idea on a reverse-proxy in a production environment as it quickly monopolize, when one of the proxied webservers badly crash, a huge amount of httpd process waiting for this timeout to occur … Anyway, even if the Apache timeout is increased, Firewalls or browsers don’t like idle TCP/IP session either… without speaking of the users ;-) Regarding my problem, I tried to disable every modules (except mod_proxy of course), and it still doesn’t work… It seems to confirm what Rüdiger said… De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Envoyé : jeudi 2 février 2006 16:48 À : dev@httpd.apache.org Cc : [EMAIL PROTECTED] Objet : Re: Apache proxy behaviour... There is no such thing as an intermediate proxy that has any kind of 'filtering' going on that won't, on some occasions, need to 'buffer' some data. I believe even mod_include will 'wait' for tags to resolve if they split across buffers. The real questions to ask is... Why is the proxy timing out? ( I.e. Why isn't it getting the rest of the data? ) If something is always taking a huge amount of time to come up with the response then you just need to speed it up or increase your proxy timeout. Yours... Kevin Kiley In a message dated 2/2/2006 7:14:01 AM Pacific Standard Time, [EMAIL PROTECTED] writes: Hi there, I came with a problem which surprise me, as I thought Apache was working differently... We have Apache 2.0.55 working in reverse-proxy in front of different webservers. One of our website takes a long time to process requests and respond to the client. The proxy reaches its timeout and closes the connection. So, our developers created a webpage which sends small chunks of data so that the connection is never closed. I thought it would work as, for me, apache don't wait for the page to be complete before sending some chunks to the client... but instead it does ! In our configuration, Apache waits to have the entire page before sending it back to the client. Is it because of one of our module ? We are using, among other things, mod_rewrite, mod_proxy, mod_deflate, mod_security, mod_headers... Thanks for your help, Regards, Thomas.
Re: Apache proxy behaviour...
There is no such thing as an intermediate proxy that has any kind of 'filtering' going on that won't, on some occasions, need to 'buffer' some data. I believe even mod_include will 'wait' for tags to resolve if they split across buffers. The real questions to ask is... Why is the proxy timing out? ( I.e. Why isn't it getting the rest of the data? ) If something is always taking a huge amount of time to come up with the response then you just need to speed it up or increase your proxy timeout. Yours... Kevin Kiley In a message dated 2/2/2006 7:14:01 AM Pacific Standard Time, [EMAIL PROTECTED] writes: Hi there, I came with a problem which surprise me, as I thought Apache was working differently... We have Apache 2.0.55 working in reverse-proxy in front of different webservers. One of our website takes a long time to process requests and respond to the client. The proxy reaches its timeout and closes the connection. So, our developers created a webpage which sends small chunks of data so that the connection is never closed. I thought it would work as, for me, apache don't wait for the page to be complete before sending some chunks to the client... but instead it does ! In our configuration, Apache waits to have the entire page before sending it back to the client. Is it because of one of our module ? We are using, among other things, mod_rewrite, mod_proxy, mod_deflate, mod_security, mod_headers... Thanks for your help, Regards, Thomas.
3.2.6 or not
OK, I know we've had some votes on this before, but I'd like to put this in a separate thread where it's not intermixed with all kinds of other things. This is a vote for the core group. We can release the 3.2.6 tarball as is or fix the connection handler bugs (there are two of them - the buffer pointer and eagain condition Graham tracked down) and release a 3.2.7 (or 3.2.6.1). The rationale for disregarding those known issues is that the connection handler is hardly used by anyone. The rationale for NOT disregarding is that we claim this to be a stable release, and given our slow release cycle, I imagine 3.2.6 will be around for a while. Anyhow - *the core group* (you know who you are), if you think 3.2.6 should be released as is, send in your +1. Let's keep this thread strictly a vote, without it turning into a discussion (we can discuss things in other threads). My official vote is +0. (To see what this means read http://httpd.apache.org/dev/guidelines.html) Grisha
AW: Apache proxy behaviour...
> -Ursprüngliche Nachricht- > Von: Matthieu Estrade > > The reverse proxy read a brigade, then forward it to the > client. It should not > buffer the response but forward block of data. Maybe it's > because of deflate mod_deflate buffers definitely. You need to turn it off for such pages or you need to write a lot of garabage data to make it flush. > or mod_security... Maybe if you check the outgoing responses. If not I would say no. > > But this behaviour is not normal imho. It is :-(. This has something to do with the improper returning of the EAGAIN status code in the filter chain. BTW: It currently works with mod_proxy_ajp in httpd 2.2.x, but not with mod_proxy_http. Regards Rüdiger
Re: Apache proxy behaviour...
The reverse proxy read a brigade, then forward it to the client. It should not buffer the response but forward block of data. Maybe it's because of deflate or mod_security... But this behaviour is not normal imho. Matthieu On Thursday 02 February 2006 16:13, CASTELLE Thomas wrote: > Hi there, > > I came with a problem which surprise me, as I thought Apache was working > differently... > > We have Apache 2.0.55 working in reverse-proxy in front of different > webservers. > > One of our website takes a long time to process requests and respond to > the client. The proxy reaches its timeout and closes the connection. > > So, our developers created a webpage which sends small chunks of data so > that the connection is never closed. > > I thought it would work as, for me, apache don't wait for the page to be > complete before sending some chunks to the client... but instead it does > ! > > In our configuration, Apache waits to have the entire page before > sending it back to the client. Is it because of one of our module ? We > are using, among other things, mod_rewrite, mod_proxy, mod_deflate, > mod_security, mod_headers... > > Thanks for your help, > > Regards, > > Thomas.
Apache proxy behaviour...
Title: Apache proxy behaviour... Hi there, I came with a problem which surprise me, as I thought Apache was working differently... We have Apache 2.0.55 working in reverse-proxy in front of different webservers. One of our website takes a long time to process requests and respond to the client. The proxy reaches its timeout and closes the connection. So, our developers created a webpage which sends small chunks of data so that the connection is never closed. I thought it would work as, for me, apache don't wait for the page to be complete before sending some chunks to the client... but instead it does ! In our configuration, Apache waits to have the entire page before sending it back to the client. Is it because of one of our module ? We are using, among other things, mod_rewrite, mod_proxy, mod_deflate, mod_security, mod_headers... Thanks for your help, Regards, Thomas.
