Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Mail-Followup-To: apreq-dev@httpd.apache.org
To: apreq-dev@httpd.apache.org
From: Joe Schaefer <joe+gmane@sunstarsys.com>
Subject: Re: [ANN] libapreq2-2.02-dev release candidate #1
Date: 13 Nov 2003 22:43:14 -0500
Lines: 55
Message-ID: <m3brrf1up9.fsf@sol.sunstarsys.com>
References: <m3wua471zd.fsf@sol.sunstarsys.com>
 <m3k7640xh1.fsf@sol.sunstarsys.com>
 <RWM890DeHdNazlOFb9pysyAFSEjvw0CVXxbmpEuM3Cs@akmail>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Mail-Copies-To: never
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Sender: news <news@sea.gmane.org>

Markus Wichitill <mawic@gmx.de> writes:

> >>   http://httpd.apache.org/~joes/libapreq2-2.02_01-dev.tar.gz
> > Can I get a few more +1s for its release?
> 
> On SuSE Linux 9.0 with self-compiled Apache 2.0.48 (Worker), mod_perl
> 1.99_11 and Perl 5.8.2 it compiles and tests fine (I tested params and
> uploads, but not cookies). 

Great- thanks!

> Some things that I noticed, though:
> 
> 1) make install added a second "LoadModule apreq_module
> modules/mod_apreq.so" line to httpd.conf. I think I removed a few
> spaces from the first line a while ago, but that should probably not
> make a difference. 

Interesting.

> 2) $upload->size() is documented without a [TODO] marker, but doesn't
> seem to exist. 

Good catch.  You're right, it hasn't been implemented yet.  I'll try to
correct the docs before final release.

> 3) $apr->parse() returns a non-zero value on GET requests. While
> parse() isn't required for GET requests, in 1.x, it returned zero
> anyway. Hm, I just noticed parse() is gone from the docs, so I guess
> it's obsolete, but if it's still there for 1.x compatibility, it
> should probably return the same. 

There's a big difference here between 1.X and 2.X- parse() only refers 
to the body now.  The query string is parsed immediately (during new()),
so the semantics of the return value for $req->parse() are different.  I
believe the current non-zero return value is correct, given this
interpretation. 

However, if you're writing a content handler, you'll get much 
better performance out of $req->discard_request_body. You can check
$req->status for the parser's final status. It'll still be non-zero
here on a GET, but that shouldn't be so surprising.

> 4) After I had removed $apr->parse() though, in a multipart/form-data
> upload form, $apr->param() wouldn't see the content of parameters that
> came after a big upload parameter anymore. So maybe parse() is just
> missing from the docs after all? 

$req->parse is there, but we're not 100% sure what it should "do"
yet- which is why I took it out of the docs for now.  We'll have
a much better picture once we see how Apache::Request looks in 
a CGI script.

-- 
Joe Schaefer