I am using an external rewritemap program (in perl with STDOUT getting flush by each print statement) with a prefork mpm and I am seeing the returned values be returning to the wrong requests. Often the first one or two lookups return no value (from rewritelog) and after that the returned values often seem to be offset by this amount with respect to request. Logs from the program indicate that it is returning the correct value based on the input it is receiving. I have seen this occur in several 2.0.37 snapshots, the latest being httpd-2.0_20020530221254.tar.gz . The following rewrite directives are being used: Rewritelock /home/httpd/html/robot/lock Rewritemap blocked prg:/home/httpd/html/robot/check.pl A current copy of the program can be found at: http://wolff.to/robot/check.pl I have played with the lockfile (ownership, access rights and existence) and haven't seen any differences in behavior.
Created attachment 2167 [details] Working Fix against 2.0.39, but still needs some work (uses Non-Apache-Constant EAGAIN)
I tried this using the current CVS after receiving the update message and I am still seeing the problem. I am including an extract from my rewrite log. I changed the script to return the IP address it was asked to lookup which should match that of the request. The log makes it clear that it doesn't. I also included part of my httpd.conf file relating to the external map. I am running a 2.2 linux kernel. If you need other information, I should be able to probably help. I really would like to see this issue fixed. Thanjs for working on this issue. RewriteLock /home/httpd/html/robot/lock Rewritemap blocked prg:/home/httpd/html/robot/check.pl 127.0.0.1 - - [24/Jun/2002:12:02:03 --0500] [localhost/sid#81a6cc0][rid#8241120/initial] (5) map lookup OK: map=blocked key=127.0.0.1 -> val= 127.0.0.1 - - [24/Jun/2002:12:02:05 --0500] [localhost/sid#81a6cc0][rid#8241120/initial] (5) map lookup OK: map=blocked key=127.0.0.1 -> val=OK-127.0.0.1 64.24.12.167 - - [24/Jun/2002:12:02:11 --0500] [wolff.to/sid#81a6cc0][rid#8247138/initial] (5) map lookup OK: map=blocked key=64.24.12.167 -> val=OK-127.0.0.1 64.24.12.167 - - [24/Jun/2002:12:02:13 --0500] [wolff.to/sid#81a6cc0][rid#8241120/initial] (5) map lookup OK: map=blocked key=64.24.12.167 -> val=OK-64.24.12.167 64.24.12.167 - - [24/Jun/2002:12:02:14 --0500] [wolff.to/sid#81a6cc0][rid#8241120/initial] (5) map lookup OK: map=blocked key=64.24.12.167 -> val=OK-64.24.12.167 127.0.0.1 - - [24/Jun/2002:12:02:18 --0500] [localhost/sid#81a6cc0][rid#8241120/initial] (5) map lookup OK: map=blocked key=127.0.0.1 -> val=OK-64.24.12.167
This issue is not yet fixed in CVS. The patch attached to this PR has not yet been committed. I've reviewed it, though, and it seems quite on-target. I'll commit a variant of it (fixing it to use APR_EAGAIN) sometime tonight. --Cliff
Sorry this took a while. I managed to miss that you had included the patch in the bugzilla entry so that I could use it before it was committed to CVS. I just tried out the patch applied to the current CVS (about two hours old) and it seemed to fix my problem. Thanks.
Just adding: it is not fixed in apache 2.0.40, the same ugly patch from 2.0.39 is still needed.
Okay, upon further investigation, I believe the correct fix is actually this: line 3463: - ((rc = apr_procattr_io_set(procattr, APR_FULL_BLOCK, - APR_FULL_NONBLOCK, - APR_FULL_NONBLOCK)) != APR_SUCCESS) || + ((rc = apr_procattr_io_set(procattr, APR_FULL_BLOCK, APR_FULL_BLOCK, + APR_NO_PIPE)) != APR_SUCCESS) || It's because reads are set to nonblocking mode that we're getting hosed here. You shouldn't have to check for APR_EAGAIN from apr_file_read()... it's only getting returned because we told it to (by setting nonblocking mode). Oops! Please let me know if this fixes it and I'll commit the change. --Cliff
I tested the suggestion to change the read to blocking and it seemed to work correctly. (I had also removed the previous fix for this test.)
Fixed for 2.0.41. Thanks for your feedback!
*** Bug 12175 has been marked as a duplicate of this bug. ***