> Thanks for the review Geoff!

sure :)

> 
> ...
> 
>>that the appropriate status code is returned seems like a valid test
>>that we would want to keep around.  maybe keep this but issue another
>>request to test your below logic?
> 
> 
> I should have explained this... the issue is that in response to an HTTP
> request on an SSL port, mod_ssl in 2.0 issues an "HTTP/0.9" response,
> i.e. it just spits out the response body without headers.  This makes
> TestRequest.pm:lwp_call() barf.

indeed.  I've been bitten by that myself when trying to specifically test
HTTP/0.9.

http://marc.theaimsgroup.com/?l=apache-test-dev&m=102407609105935&w=2

perhaps now is a good time to fix that little bit.

> 
> That mod_ssl bug is not really a regression worth worrying about IMO:
> browsers handle the error response just fine, so I was trying to just
> detect that it sent the right response body.

that's legitimate, certainly.

> 
> Now I think about it maybe a better way to fix this would be to let
> lwp_call take an argument to allow it to *not* barf on an "HTTP/0.9"
> response:
> 
>             if ($1 ne "1.0" && $1 ne "1.1") {
>                 $error = "response had protocol HTTP/$1 (headers not sent?)";
>             }

agreed.  the stuff I proposed before is just one suggestion, but perhaps you
can think up a better idea.  0.9 is probably rare enough that it doesn't
warrant a huge interface was my thought.

> 
> But working out how lwp_call even gets *called* via GET gives me
> headaches.  Can anyone help? 

yeah.  I actually took the time to trace through the logic not too long ago.

look for the

    *$name = sub {
        my($url, $pass, $keep) = prepare(@_);
        local $RedirectOK = exists $keep->{redirect_ok}
            ? $keep->{redirect_ok}
            : $RedirectOK;
        return lwp_call($method, undef, $url, @$pass);
    };

logic in TestRequest.pm - it defines &$name for each of @EXPORTS, so when
you call GET from foo.t you are either using the cv from lwp or A-T's own
implementation if lpw isn't available.  if you stick a few print statements
in that subroutine, as well as prepare(), you'll see what's going on.  the
shortcut logic just below that is for GET_OK, GET_BODY, etc.

where it threw me was the $UA global, which is an LWP::UserAgent _subclass_
object - I was looking for how the 'username => $foo' magic worked, and it
turns out that get_basic_credentials() is an overridden subroutine.  highly
magical :)

HTH

--Geoff


Reply via email to