Bug 28637 - mod_rewrite out of sync
Summary: mod_rewrite out of sync
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_rewrite (show other bugs)
Version: 2.0.49
Hardware: PC Linux
: P3 major (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2004-04-27 20:05 UTC by rodrigo campos
Modified: 2004-11-16 19:05 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description rodrigo campos 2004-04-27 20:05:55 UTC
When using an external rewrite program, after some thousand requests, 
mod_rewrite seems to get out of sync with the program.

I noticed that the RewriteLock file is not being created.

The same mod_rewrite ruleset works perfectly with apache 1.3.29, and in this 
case the rewritelock file is created accordingly.
Comment 1 André Malo 2004-04-27 20:21:18 UTC
Hmm. What does it mean exactly? One request serving the stuff of another? Do you
have an example?

Is it a vanilla installation?

The rewritelock may be a semaphore or something else so that's probably not a
Which MPM are you using?

Comment 2 Cliff Woolley 2004-04-27 20:37:04 UTC
I have heard of this happening before -- mod_cgid had trouble like this at some 
point in the past.  I think I've even *seen* it happen with mod_rewrite 1.3.x 
at some point in the distant past because I forgot to set up a lock file.  If 
the lock file were missing, I could easily believe that map program would get 
out of sync, since it just takes an argument line on stdin and writes its 
response line to stdout.  If apache gets confused as to which stdout goes with 
which stdin (because inputs are coming from multiple places simultaneously), 
badness will happen.
Comment 3 rodrigo campos 2004-04-27 20:56:37 UTC
The problem occurs with the worker and the prefork MPM.

Apache is configured with 3 virtualhosts, all three use mod_rewrite but only 
two of them use (different) rewritemap external programs.

By 'out of sync' I mean that one request is serving the stuff of another.

eg. the external program writes 'foo' to stdout but apache redirects the user 
to 'bar', which was the answer for other request.

Apache was compiled without any patches, using the usual configure/make/make 
Comment 4 André Malo 2004-04-27 21:08:23 UTC
Well, I see two possible POFs:

1) The program is not locked properly, but if the RewriteLock directive is used,
it should work (nothing in the errorlog, right?)

2) The external program thinks too early that the current line is read. In
previous versions this could be the case if the key contained a newline. May I
see, how you read the stuff from stdin?
Comment 5 rodrigo campos 2004-04-27 21:23:02 UTC
There's no error in the errorlog, the problem begins after a random number of 
requests (usually many thousands), and stops after a restart in the Apache 

The same external program works perfectly with Apache 1.3.29, basically it 
reads a ascii file and creates a linked-list in memory, with a key-value 
structure, the argument passed on stdin is matched against some patterns and 
returns a complete URL.

This is the ruleset that uses the rewritemap:

   RewriteCond  ${redirmap:%{REQUEST_URI}}      ^(https?.*)
   RewriteRule  .       %1      [R,L,NE]

I read stdin this way:

#define BUFSIZE 512
char line[BUFSIZE];
setvbuf (stdout, NULL, _IOLBF, 0);
while (fgets (line, sizeof (line), stdin))
/* write to stdout */
printf ("%s\n", (char *) cp);

I hope this helps.
Comment 6 André Malo 2004-04-27 21:31:09 UTC
Ha! The bufsize can be the problem. The input string may be (much) longer and is
split that way -> and gets out of sync. You should use 8192 bytes for the buf,
which is the distributed maximum length of the request line (so mostly the

You might try some test requests with more than 512 bytes before to see if the
sync error really happens then.
Comment 7 rodrigo campos 2004-04-27 22:18:34 UTC
I've just tested making a request with more than 512 bytes and the bug was 
reproduced, recompiled my program with a BUFSIZE of 8192 and now it's working 

Thank you very much for your cooperation and sorry for any inconvenience, 
since it was not a bug in Apache.

I changed the resolution status to INVALID.
Comment 8 André Malo 2004-04-28 07:13:26 UTC
Thanks for the feedback!