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 2004/08/04 10:10:52 UTC
apache/content_length_header todo failures
Geoff,
so what's going to happen to these todo tests that you've added recently?:
t/apache/content_length_header..........ok 2/24# Failed test 2 in
t/apache/content_length_header.t at line 37 *TODO*
t/apache/content_length_header..........ok 5/24# Failed test 5 in
t/apache/content_length_header.t at line 47 *TODO*
This can't stay this way for the release, since everybody and their mom
are going to complain about this. If it's not going to be fixed by
Apache folks (and it's not a mod_perl problem), then may be we should
turn them into ok tests and instead document the issues?
--
__________________________________________________________________
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: apache/content_length_header todo failures
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Stas Bekman wrote:
>
>>Geoff,
>>
>>so what's going to happen to these todo tests that you've added recently?:
>>
>>t/apache/content_length_header..........ok 2/24# Failed test 2 in
>>t/apache/content_length_header.t at line 37 *TODO*
>>t/apache/content_length_header..........ok 5/24# Failed test 5 in
>>t/apache/content_length_header.t at line 47 *TODO*
>>
>>This can't stay this way for the release, since everybody and their mom
>>are going to complain about this.
>
>
> yeah, I was thinking about this. here is my take on it.
>
> we're testing apache functionality, not our own, so we can safely adjust the
> expectations to meet what we know apache is going to do. basically, I would
> view the apache tests as ones that, upon failure, let us know that the
> underlying apache core has changed so it gives us something to investigate.
+1
> really, I made these TODO because I wasn't sure about the proper behavior.
> I think that I am now :)
>
>
>>If it's not going to be fixed by
>>Apache folks (and it's not a mod_perl problem), then may be we should
>>turn them into ok tests and instead document the issues?
>
>
> not to prolong the discussion (perhaps this is a better place for it anyway)
> but as I said in my last message I don't see that there is a bug - the tests
> show that GET and HEAD present equivalent C-L headers except for the
> specific case where you have a content handler (plus filters) that results
> in zero content for the request (which is extremely rare). and this case is
> specifically different because it is coded to protect against handlers that
> (incorrectly) call r->header_only, which presumably is less rare (since it
> is a migration issue) than serving zero content.
OK, I've committed a change, which makes this special case that Boris
has raised as a separate test. Leaving GET vs. HEAD parts as before. so
please drop the TODO part, turn them into OKs and document why the
behavior is in the way it is.
Once you did, we will need to document that in the docs (simply copy the
comments into the docs, so please make them verbose :)
> but I'll certainly accept that my analysis is off, so if you don't agree
> let's start from the begining and flesh out what we really need to happen.
> that is, if you don't see it that way, I'm obviously sufficiently dense at
> the moment that I need it explained to me again, starting with what the real
> issue is and moving to exactly what part of apache core looks to be at fault.
No, it's good.
It's funny how quite a few people had a problem with C-L at the same time :)
--
__________________________________________________________________
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: apache/content_length_header todo failures
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Geoff,
>
> so what's going to happen to these todo tests that you've added recently?:
>
> t/apache/content_length_header..........ok 2/24# Failed test 2 in
> t/apache/content_length_header.t at line 37 *TODO*
> t/apache/content_length_header..........ok 5/24# Failed test 5 in
> t/apache/content_length_header.t at line 47 *TODO*
>
> This can't stay this way for the release, since everybody and their mom
> are going to complain about this.
yeah, I was thinking about this. here is my take on it.
we're testing apache functionality, not our own, so we can safely adjust the
expectations to meet what we know apache is going to do. basically, I would
view the apache tests as ones that, upon failure, let us know that the
underlying apache core has changed so it gives us something to investigate.
really, I made these TODO because I wasn't sure about the proper behavior.
I think that I am now :)
> If it's not going to be fixed by
> Apache folks (and it's not a mod_perl problem), then may be we should
> turn them into ok tests and instead document the issues?
not to prolong the discussion (perhaps this is a better place for it anyway)
but as I said in my last message I don't see that there is a bug - the tests
show that GET and HEAD present equivalent C-L headers except for the
specific case where you have a content handler (plus filters) that results
in zero content for the request (which is extremely rare). and this case is
specifically different because it is coded to protect against handlers that
(incorrectly) call r->header_only, which presumably is less rare (since it
is a migration issue) than serving zero content.
but I'll certainly accept that my analysis is off, so if you don't agree
let's start from the begining and flesh out what we really need to happen.
that is, if you don't see it that way, I'm obviously sufficiently dense at
the moment that I need it explained to me again, starting with what the real
issue is and moving to exactly what part of apache core looks to be at fault.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org