Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 20 Oct 2003 01:24:43 -0500 (CDT)
From: Randy Kobes <randy@theoryx5.uwinnipeg.ca>
To: apreq-dev@httpd.apache.org
Subject: [apreq-2] posting with libapreq_cgi
Message-ID: <Pine.LNX.4.56.0310200119290.21000@theoryx5.uwinnipeg.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,
I'm confused about something in a group of the libapreq_cgi
tests, and was wondering if someone had an idea ... The
following occurs both on linux and on Win32, under
Apache/2.0.47. One of the tests constructs a long query out
of lots of key=value pairs. Posting the data as
============================================================
my $body = POST_BODY($script, content => "$query;$filler");
ok t_cmp($len,
         $body,
         "POST big data");
}
===========================================================
(where $query is the query, $filler is some filler, and $len
is the length of the key/value pairs) is successful. However,
if one removes the filler, as in
===========================================================
my $body = POST_BODY($script, content => $query);
ok t_cmp($len,
         $body,
         "POST big data");
}
===========================================================
(which is how the mod_apreq test is constructed under env/t)
then the tests fail. Examining what goes wrong shows that the
last key=value pair of $query isn't being picked up. I think
this is related to the apreq_env_read sub of libapreq_cgi:
=============================================================
APREQ_DECLARE(apr_status_t) apreq_env_read(void *env,
                                           apr_read_type_e block,
                                           apr_off_t bytes)
{
    dCTX;
    if (ctx->bb == NULL) {
        apr_bucket_alloc_t *alloc = apr_bucket_alloc_create(ctx->pool);
        apr_file_t *in;
        apr_bucket *stdin_pipe;

        ctx->bb = apr_brigade_create(ctx->pool, alloc);
        apr_file_open_stdin(&in, ctx->pool);
        stdin_pipe = apr_bucket_pipe_create(in,alloc);
        APR_BRIGADE_INSERT_HEAD(ctx->bb, stdin_pipe);
    }

    return apreq_parse_request(apreq_request(env,NULL), ctx->bb);
}
===============================================================
If an eos bucket is inserted at the end of the ctx->bb brigade,
as in
================================================================
Index: libapreq_cgi.c
===================================================================
RCS file: /home/cvs/httpd-apreq-2/env/libapreq_cgi.c,v
retrieving revision 1.11
diff -u -r1.11 libapreq_cgi.c
--- libapreq_cgi.c	20 Oct 2003 05:25:14 -0000	1.11
+++ libapreq_cgi.c	20 Oct 2003 05:57:31 -0000
@@ -187,12 +187,14 @@
     if (ctx->bb == NULL) {
         apr_bucket_alloc_t *alloc = apr_bucket_alloc_create(ctx->pool);
         apr_file_t *in;
-        apr_bucket *stdin_pipe;
+        apr_bucket *stdin_pipe, *b;

         ctx->bb = apr_brigade_create(ctx->pool, alloc);
         apr_file_open_stdin(&in, ctx->pool);
         stdin_pipe = apr_bucket_pipe_create(in,alloc);
         APR_BRIGADE_INSERT_HEAD(ctx->bb, stdin_pipe);
+        b = apr_bucket_eos_create(alloc);
+        APR_BRIGADE_INSERT_TAIL(ctx->bb, b);
     }

     return apreq_parse_request(apreq_request(env,NULL), ctx->bb);
===================================================================
then the tests with and without the filler succeed. What
I was wondering is if the insertion of the eos bucket at the
end should be done?

Although this may fix this problem, I'm not sure if it's the
right thing in general. Trying one of the cookie tests
====================================================================
    my $test  = 'netscape';
    my $key   = 'apache';
    my $value = 'ok';
    my $cookie = qq{$key=$value};
    ok t_cmp($value,
             GET_BODY("$script?test=$test&key=$key", Cookie => $cookie),
             $test);
=====================================================================
results in a failure, with or without the eos insertion patch
above. A trace shows that a "Cookie" header is being found, but
there's no data associated with it. However, this may be
an unrelated problem ... Thanks.

-- 
best regards,
randy