David Wheeler wrote:
On Monday, June 23, 2003, at 05:08  AM, Geoffrey Young wrote:

I especially need help with the "keep_alive" parameter to user_agent()


keep_alive enables connection persistence, where the same connection is used to process multiple requests. the only use of it that I have seen is in http11/basicauth.t

  my $request_num = Apache::TestRequest::user_agent_request_num($res);

  ok $request_num == 3; #1 => no credentials
                        #2 => 401 response with second request
                        #3 => 200 with guest/guest credentials

also, from the LWP::UserAgent manpage:

The C<keep_alive> option also has the effect of loading and enabling the new experimental HTTP/1.1 protocol module.

so keep_alive may be more of a shorthand way of enabling (and testing) HTTP/1.1 compliance rather than just persistent connections (which can be used in both protocols).

as for the code changes, Stas should probably review them first. however, the docs look great - nice work.


Thanks Geoffrey. I've added in your comments, and attach a new patch. Again, here's what it does:

* Attempts to document all of the important functions of Apache::TestRequest. Comments and corrections would be much appreciated. I especially need help with a description of what OPTIONS() does.

* Exports UPLOAD from Apache::TestRequest. Was this an oversight?

I guess it just wasn't used?

* Changes the way the redirect_ok parameter works so that it affects only that _that call_ to the function. Afterward it should revert to the old value of $RedirectOK. I use local() to do this.

* Changes user_agent() so that the LWP::UserAgent "requests_redirectable" parameter actually does something useful vis-à-vis $RedirectOK.

* Added "SEE ALSO" section to Apache::Test. Note that this section, and the same section of Apache::TestRequest, points to Apache::TestMM, which currently has no documentation.

Thank you very much David, I've committed your patches and the docs. In the future please try to submit each feature change separately. Thanks.



re: OPTIONS, see section 9.2 in http://www.faqs.org/rfcs/rfc2616.html

this is how httpd-test uses it:

#httpd-test/perl-framework/t/apache/options.t
use strict;
use warnings FATAL => 'all';

use Apache::Test;
use Apache::TestRequest;

my @urls = qw(/);

plan tests => @urls * 2, \&have_lwp;

for my $url (@urls) {
    my $res = OPTIONS $url;
    ok $res->code == 200;
    my $allow = $res->header('Allow') || '';
    ok $allow =~ /OPTIONS/;
}

So I've trimmed all the OPTIONS entries in the doc, but the main one. I think the rest aren't useful at all.


---

re: =head1 SYNOPSIS

I'd suggest to have a small synopsis with mod_perl 1 and another on mod_perl 2? Or have no mod_perl specific api at all?

---

I didn't modify the content, but mainly adding C<> for modules and re-wrapping as a result (just pod fixups). Hopefully I'll have a chance to read through once I catch up with the emails backlog. For now I've just committed as is.

For the next pass, it'd be cool to move =item to be =head3 so that the items will appear in the TOC when rendered in HTML. That's the practice I've started to use on the perl.apache.org and it seems to do pretty well.

Looking forward for more docs ;)

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com



Reply via email to