Summary: | rewritemap using external map program gets out of sync | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | Bruno Wolff III <bruno> |
Component: | mod_rewrite | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | CLOSED FIXED | ||
Severity: | normal | CC: | camposr |
Priority: | P3 | Keywords: | PatchAvailable |
Version: | 2.0.40 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
Attachments: | Working Fix against 2.0.39, but still needs some work (uses Non-Apache-Constant EAGAIN) |
Description
Bruno Wolff III
2002-05-31 03:40:34 UTC
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! |