Re: GIF contents not "coming out"
- Hi Chris,
Finally I've got a chance to analyze your problem.
> The "GIF" isn't actually a GIF at all - it was the "favicon.ico" iconmod_perl wasn't doing anything like that. The problem was in the contents of
> 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?
favicon.ico. .ico files seem to start with the sequence \000\000 and mod_perl
2.0 had a bug dealing with parsing printed headers immediatelly followed by
response body starting with '\0'. I've reduced your test to a one liner script:
print "Content-type: image/x-icon\n\n\000\000\001\000";
It's now fixed in the cvs.
> On a personal note - I think the whole mod_perl header system shouldNobody prevents you from printing your own headers. It's just much slower. I
> 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...
just wrote a new docs section explaining the differences and nuances of
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@... 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