Stas Bekman wrote:
Geoffrey Young wrote:


yeah, that's a consideration. I've cleaned up the code to remove all back-compat stuff for versions prior to 2.0.46. I'll let it run through my nightly builds and see how it went tomorrow.



everything looks ok, with the exception of t/filter/TestFilter/in_str_consume.pm, which hangs even though the comments say it should only hang for 2.0.40 and older.


I can't reproduce that. please post a complete bug report so I can try to match your setup.

forthcoming...


-/* api change in 2.0.40-ish */
-#if (MODULE_MAGIC_NUMBER_MAJOR >= 20020628)
-#   define MP_FILTER_HANDLER(f) f, NULL
-#else
-#   define MP_FILTER_HANDLER(f) f
-#endif
+#define MP_FILTER_HANDLER(f) f, NULL


there is no need in this define then, should go and replace it with f, NULL where it's used. (can do that in a separate pass).

oh, ok. I guess I figured we wanted to keep the macro - it didn't occur to me the workaround was the reason for the macro :)


         # this is not needed in newer Apache versions, however older
-        # versions (2.0.40) will repeatedly call this filter, waiting
+        # versions (2.0.46) will repeatedly call this filter, waiting
         # for EOS which will never come from this filter so, after
         # several invocations mark the seen_eos flag, to break the
         # vicious cirle
+        # BACK_COMPAT_MARKER: make back compat issues easy to find
         if ($count > 10) {
             $filter->seen_eos(1);
         }


but the problem doesn't happen with 2.0.46, only in 2.0.40. why s/2.0.40/2.0.46/?

well, if it's not reproducable then we'll remove that comment and code alltogether. if it is reproducable, then it affects 2.0.46 :)


in either case, I'm working up a test case and will report back. I'll hold off until this issue is cleared up.

--Geoff



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to