-------- Original Message --------
Subject: Re[2]: GIF contents not "coming out"
Date: Wed, 3 Mar 2004 21:55:21 +1100
From: Chris Drake <[EMAIL PROTECTED]>
To: Stas Bekman <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Hi Stas,
Cool - glad you found it! Sorry I was so "harsh" with my $0.02 (long night coding tends to shorten my temper - oops).
You might like to mention in your manual how to set the response code, like "HTTP/1.1 304 NOT MODIFIED" or whatever. I noticed that you appear to be doing some "smarts" and sending this back (in preference to what I really printed) when you detect my etag and/or "last modifed" headers match the request, but I'm sure other people (and me in future) will want to set these codes - so mentioning how to do this in the "Generating_HTTP_Response_Headers" section would be ideal.
Incadentally - there's a cosmetic bug with the code which does that too: I find my log files full of this:-
[Mon Mar 01 00:13:54 2004] [warn] /cache.asp/blank1x1.gif did not send an HTTP header
but upon close investigation, my script does send the correct stuff, and the correct (well - correctED to be precise - you code stripped out my reply and sent "304 NOT MODIFED" instead - which is correct) headers come back to the browser just fine - it's only when the original request had an "IF-Modified-Since:" condition that the error turns up in the logs (even though it wasn't an error).
If you have time to experiment, I noticed a horrendous "memory leak" *or* code "zombieing" problem using the "worker MPM" instead of prefork with mod_perl and DBI and oracle. Problem vanished when I changed back to prefork. Dunno if it was mod_perl, DBI, or oracle to blame unfortunately - but I thought I'd tell you in case it helps. I'm using RedHat enterprise linux 3 with mod_perl-1.99_09
Kind Regards, Chris Drake
Wednesday, March 3, 2004, 7:26:20 PM, you wrote:
SB> Hi Chris,
SB> Finally I've got a chance to analyze your problem.
The "GIF" isn't actually a GIF at all - it was the "favicon.ico" icon file - so my guess is that mod_perl is sneaking a peek at what comes next (expecting GIF89a or whatever) and doing something wrong when that 'aint it. I realize I shouldn't be saying "image/gif" in this case, but then - mod_perl shouldn't be screwing up my headers just 'coz of that mistake?
SB> mod_perl wasn't doing anything like that. The problem was in the contents of
SB> favicon.ico. .ico files seem to start with the sequence \000\000 and mod_perl
SB> 2.0 had a bug dealing with parsing printed headers immediatelly followed by
SB> response body starting with '\0'. I've reduced your test to a one liner script:
SB> print "Content-type: image/x-icon\n\n\000\000\001\000";
SB> It's now fixed in the cvs.
On a personal note - I think the whole mod_perl header system should have been omitted. If a script wants to send the headers, it should be allowed to, without interference. Making people learn an indeterminate number of new custom non-standard callbacks like "content_type()" and whatever the ones are for caching, p3p, cookies, accept, encoding, charsets, and so forth is silly - since everyone who knows they're needed already knows how to send them normally - hence the extra bunch of callback stuff just wastes everyone's time. Just my $0.02...
SB> Nobody prevents you from printing your own headers. It's just much slower. I
SB> just wrote a new docs section explaining the differences and nuances of
SB> headers generating:
SB> http://perl.apache.org/docs/2.0/user/coding/coding.html#Generating_HTTP_Response_Headers
__________________________________________________________________ Stas Bekman JAm_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
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
