Mailing-List: contact test-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: test-dev@httpd.apache.org
Message-ID: <40337CA2.1090201@modperlcookbook.org>
Date: Wed, 18 Feb 2004 09:54:26 -0500
From: Geoffrey Young <geoff@modperlcookbook.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
MIME-Version: 1.0
To: test-dev@httpd.apache.org
Subject: Re: [PATCH] vhost_socket tweak
References: <20040218100855.GA10203@redhat.com>
 <4033713B.1060906@modperlcookbook.org> <20040218143010.GC10203@redhat.com>
In-Reply-To: <20040218143010.GC10203@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


> 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