You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2003/08/07 23:33:36 UTC
Re: mod_perl: Handling of status 304 (not modified)
Dan Wilga wrote:
>> [Fri Jul 18 05:56:12 2003] [error] 16872: ModPerl::Registry:
>>304:Unknown error 304 at [module name and line number].
>>
>>I traced this to an oversight in the file modperl_filter.c. It did
>>not consider the 304 to be a successful return. I made the following
>>modification, and now all's well:
>>
>>--- orig/mod_perl-1.99_09/src/modules/perl/modperl_filter.c
>>2003-04-18 01:34:12.000000000 -0400
>>+++ src/modules/perl/modperl_filter.c 2003-07-18 11:19:07.000000000 -0400
>>@@ -114,5 +114,5 @@
>> return APR_SUCCESS; /* XXX: HTTP_MOVED_TEMPORARILY ? */
>> }
>>- else if (status != OK) {
>>+ else if (status != OK && status != HTTP_NOT_MODIFIED) {
>> ap_log_error(APLOG_MARK, APLOG_WARNING,
>> 0, r->server, "%s did not send an HTTP header",
This is not right, since status doesn't really contain HTTP status, but the
execution status (OK or error), with HTTP_MOVED_TEMPORARILY being just a hack.
>> Can you please post a simple test and the relevant configuration? You
>> can even send a new test for our ModPerl-Registry test suite.
>
>
> Unfortunately, I don't have the time to post a formal test case, but I
> can quite easily give you the test Registry script to base one on:
[...]
Dan, unfortunately I can't reproduce this problem (I think I did some time
ago, but not any longer). I've added a formal test to the mod_perl test suite
which works for me. Can you please get the latest mod_perl 2.0 cvs
http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distributionand
see if it works for you. If it doesn't try to break it.
After you complete the normal build and test, do:
cd ModPerl-Registry
t/TEST -v 304
the relevant files are t/304.t and t/cgi-bin/304.pl
Thanks a lot.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl: Handling of status 304 (not modified)
Posted by Stas Bekman <st...@stason.org>.
Dan Wilga wrote:
> perl Makefile.PL MP_COMPAT_1X=1 MP_AP_PREFIX=../httpd-2.0.47
>
> Reading Makefile.PL args from @ARGV
> MP_COMPAT_1X = 1
> MP_AP_PREFIX = ../httpd-2.0.47
> Configuring Apache/2.0.47 mod_perl/1.99_10-dev Perl/v5.8.0
> Failed to obtain the MPM name at lib/Apache/Build.pm line 169.
Thanks for the catch, please try with the latest cvs, it should work now.
>> After you complete the normal build and test, do:
>>
>> cd ModPerl-Registry
>> t/TEST -v 304
>>
>> the relevant files are t/304.t and t/cgi-bin/304.pl
>
>
> What originally led me to look into this problem was a malformed date in
> the If-Modified-Since header, that a badly-written client was sending,
> like so:
>
> If-Modified-Since: Thu Jul 3 00:00:00 2003
>
> In the current version, if I test with a valid date, it always works as
> expected. I'm fairly positive that it failed in 1.99_09, though.
does the test fail if you copy it to the 1.99_09 checkout?
> I can still reproduce the problem on a fully-working server, with the
> CVS version, if I use this malformed date with GET and some URLs.
> Whether or not it fails seems to depend on something I can't nail down;
> perhaps it's the length of the URL, or even of the content. I can't
> reproduce the problem by modifying your 304.t to use this date.
Well, if you figure out how to break it, please send a patch. Meanwhile I'm
extending this test to verify bogus dates as well. Will commit the change shortly.
> Installing my original patch does seem to clear up the problem, even
> now. Of course, it's hard to tell if maybe it's just masking the symptom.
Could be. It's definitely not the right patch, since the return status has
nothing to do with HTTP status, however it could be a bug in the httpd code.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl: Handling of status 304 (not modified)
Posted by Dan Wilga <dw...@MtHolyoke.edu>.
At 2:33 PM -0700 8/7/03, Stas Bekman wrote:
>Dan, unfortunately I can't reproduce this problem (I think I did
>some time ago, but not any longer). I've added a formal test to the
>mod_perl test suite which works for me. Can you please get the
>latest mod_perl 2.0 cvs
>http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distributionand
>see if it works for you. If it doesn't try to break it.
I can't get this to compile as-is. Here's what happens:
perl Makefile.PL MP_COMPAT_1X=1 MP_AP_PREFIX=../httpd-2.0.47
Reading Makefile.PL args from @ARGV
MP_COMPAT_1X = 1
MP_AP_PREFIX = ../httpd-2.0.47
Configuring Apache/2.0.47 mod_perl/1.99_10-dev Perl/v5.8.0
Failed to obtain the MPM name at lib/Apache/Build.pm line 169.
`whereis apxs` only returns one option, so I'm not sure where the
confusion is. When I run apxs manually, I get:
apxs -q MPM_NAME
prefork
so I just hacked sub mpm_name() to return 'prefork', and it worked.
>After you complete the normal build and test, do:
>
>cd ModPerl-Registry
>t/TEST -v 304
>
>the relevant files are t/304.t and t/cgi-bin/304.pl
What originally led me to look into this problem was a malformed date
in the If-Modified-Since header, that a badly-written client was
sending, like so:
If-Modified-Since: Thu Jul 3 00:00:00 2003
In the current version, if I test with a valid date, it always works
as expected. I'm fairly positive that it failed in 1.99_09, though.
I can still reproduce the problem on a fully-working server, with the
CVS version, if I use this malformed date with GET and some URLs.
Whether or not it fails seems to depend on something I can't nail
down; perhaps it's the length of the URL, or even of the content. I
can't reproduce the problem by modifying your 304.t to use this date.
Installing my original patch does seem to clear up the problem, even
now. Of course, it's hard to tell if maybe it's just masking the
symptom.
--
Dan Wilga dwilga@mtholyoke.edu
Web Technology Specialist http://www.mtholyoke.edu
Mount Holyoke College Tel: 413-538-3027
South Hadley, MA 01075 "Oook."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org