note
tye
<p>
To be honest, that makes no sense. /m only impacts the meaning of ^ and the only '^'s in the regex you show are inside a character class and so aren't impacted by /m.
</p><p>
If this change fixed the mod_perl client, then it <em>does</em> remind me of mod_perl bugs I've seen before. Usually these bugs are heisenbugs, however, coming and going depending on how long a given Apache process has been running, though I guess I have seen some persistent ones (and rarely ones that persisted until the master Apache process was restarted).
</p><p>
In any case, bug(s) I've seen cause rather weird regex behavior. For example, <c>/\d\d/g</c> will sometimes fail on a string full of pairs of digits (and you'll see a node temporarily tagged as being written "never"). Or I've had several complex regexes that mod_perl refused to parse even though they were correct and worked outside of mod_perl. Changing to a different delimiter was the most common solution.
</p><p>
Although I don't understand your explanation of the workings of this bug, it certainly looks like a Perl bug if dropping /m does what you describe (note that Perl bugs are more likely to be visible in mod_perl because the Perl interpretter runs for so long). It sounds like perhaps the /m on the one regex is, in mod_perl, making the <c>/^END\r\n/</c> behave as if it had a /m on it.
</p>
<div class="pmsig"><div class="pmsig-22609"><p align="right">
- [tye]<tt> </tt>
</p></div></div>
654127
654534