Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
Bill Marrs wrote:
[...]
You would probably wish to append your script with
additional output after the empty string? Something like:
#!/usr/bin/perl
$|=1;
print Content-Type: text/html\n\n;
print hello worldP;
# This line causes the error (?)
print ;
print hello againP;
---
When I do this, the mod_perl variant of the script fails to print hello
againP.
mod_cgi prints everything just fine and gets no errors.
I changed my test script to print a bunch of `date`'s
http://shevek.kenyonhill.com/cgi/test.pl
http://shevek.kenyonhill.com/perl/test.pl
Sorry for getting late to this thread, this is a bug in mod_deflate. You don't
see it in mod_cgi, because mod_cgi doesn't really handle buffering and
flushing, since it just reads the data from the pipe to the process.
mod_deflate didn't follow the deflate() spec, saying that the caller shouldn't
call deflate, when there is no data to deflate. Try this patch:
Index: modules/filters/mod_deflate.c
===
RCS file: /home/cvs/httpd-2.0/modules/filters/mod_deflate.c,v
retrieving revision 1.26.2.5
diff -u -r1.26.2.5 mod_deflate.c
--- modules/filters/mod_deflate.c 17 May 2003 18:27:43 - 1.26.2.5
+++ modules/filters/mod_deflate.c 5 Aug 2003 06:37:59 -
@@ -529,9 +529,11 @@
if (APR_BUCKET_IS_FLUSH(e)) {
apr_bucket *bkt;
-zRC = deflate((ctx-stream), Z_SYNC_FLUSH);
-if (zRC != Z_OK) {
-return APR_EGENERAL;
+if (ctx-stream.avail_in 0) {
+zRC = deflate((ctx-stream), Z_SYNC_FLUSH);
+if (zRC != Z_OK) {
+return APR_EGENERAL;
+}
}
ctx-stream.next_out = ctx-buffer;
Feel free to submit this bug report and the fix to httpd-dev. Please let me
know if you do that, so I won't duplicate it. But I'd prefer that you do it so
you can make sure that it gets fixed in the next release, since you need it
working.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] Child process exited
So, has anyone checked out my test case? Any results (good or bad)? As I said in my last post, I'm getting this for differing amounts of whitespace in my template files, so it isn't just one tag to be removed everywhere. I have something like 30 template files, most of them much more complex than the one in the test case, so it would take a real long time to go through each one, trying to get them to work by trial and error. So I can't really do anything until I know what causes this and how to work around it. Looking forward to getting this working... Thanks J-S ___ Jean-Sébastien Guay [EMAIL PROTECTED] Software Developer, Hybride http://www.hybride.com Piedmont, Québec, Canada
Re: Working directory of script is / !
On Wed, 30 Jul 2003, Stas Bekman wrote: Perrin Harkins wrote: On Tue, 2003-07-29 at 07:23, Stas Bekman wrote: That's correct. This is because $r-chdir_file in compat doesn't do anything. The reason is that under threaded mpm, chdir() affects all threads. Of course we could check whether the mpm is prefork and do things the old way, but that means that the same code won't work the same under threaded and non-threaded mpms. Hence the limbo. Still waiting for Arthur to finish porting safecwd package, which should resolve this problem. When he does finish it, won't we make the threaded MPM work just like this? It seems like it would be reasonable to get prefork working properly, even if the threaded MPM isn't ready yet. It's a tricky thing. If we do have a complete implementation then it's cool. If not then we have a problem with people testing their code on prefork mpm and then users getting the code malfunctioning on the threaded mpms. I think we could have a temporary subclass of the registry (e.g.: ModPerl::RegistryPrefork) which will be removed once the issue is resolved. At least it'll remind the developers that their code won't work on the threaded mpm setups. However if they make their code working without relying on chdir then they can use Modperl::Registry and the code will work everywhere. What's wrong with having the chdir code check for the threaded mpm, and, if it detects it, generate a warning that describes the situation? Admittedly, I have a difficult time understanding someone who tests under one mpm, and then releases under another mpm without testing. I realize there are people who do this sort of thing; I'm merely stating that I have difficulty understanding them. Ed
RE: PerlModule options?
Hi Perrin, I see your point. However I'm speaking about one simple templating module exporting 2 functions that are used to generate HTML in every other module on the server. So it'll be pollution but bearable ;-) Thank you, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 8:29 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: PerlModule options? On Tue, 2003-08-05 at 04:55, [EMAIL PROTECTED] wrote: loads the module but doesn't import the symbols since it is equivalent to the use Foo::Bar (). Therefore I should use use Foo::Bar in each program only to make the import. Correct. Is there other way to load the module and import the symobols specified in @EXPORT at mod_perl reloading time, without adding a special line in each and every script using them? No, that would be Bad. By putting a use Foo in each module that wants to import functions from Foo, you are explicitly saying please pollute my namespace to Foo. That sort of thing shouldn't happen unless you request it. Perhaps some options passed to PerlModule though adding (...) doesn't help since PerlModule expects a list of modules. There's no way it could since PerlModule has no way of knowing what namespaces you are going to want polluted. - Perrin
Threading issue in 5.6 and 5.8
Hi everybody, I have a simple script that uses POP3Client to retrieve emails. It turns out that I can run this script only once, or more if all the subsequent requests are to the same script. That is say, my script's name is A, and I execute the same script 20 times subsequently there is no problem. But if I execute B after A, and then execute A again, then I have a problem and the problem is that there is a socket error. This happens only on Windows machines. I learnt that this is a common problem and that it is because of threads. Making number of threads on apache 1 solves the problem, but then a refresh is extremely slow, cause it seems KeepAlive makes the thread stop responding to the refresh until keep alive times out. Ok, here is the real question. Should I move to 5.8 and if I should, what are the general issues that I have to be careful about. One more thing is that, can I run perl 5.8 with mod_perl 1.0? Is that possible, or do I also have to move to mod_perl 2 and apache 2? Thanks __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: http responses piped to STDERR
Michael Pohl wrote: I'm (very) occasionally seeing the output of Apache::Registry scripts sent to STDERR instead of STDOUT. That is, the entire http response (headers included) appears in my error log, while nothing at all is displayed to the client. Could someone kick me towards what I should look into here? Do you have this stub in all your files? use strict; use warnings; or if perl 5.6 PerlWarn On in httpd.conf and use strict; in all files. this should reduce the numbed of inconsistent misteries to zero. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
