You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by "Philippe M. Chiasson" <go...@cpan.org> on 2003/10/22 18:47:22 UTC

[BUG] mod_apreq & mod_proxy stalls POST requests

I believe I've encountered an interaction problem with mod_apreq and mod_proxy.

I basically have to proxy certain requests to different locations based on incoming
arguments. This works as long as you make GET requests. If I read the POST data early
with apreq (translate_name phase) and subsequently trigger a proxy request, mod_proxy
somehow gets stuck trying to read data from the client.

The following test module illustrate this

GET http://localhost:8529/apreq_proxy_test?loc=http://www.apache.org/

Works perfectly fine

but

echo loc=http://www.apache.org/ | POST http://localhost:8529/apreq_proxy_test

Will just hang there, while the error_log shows:

[Wed Oct 22 09:45:27 2003] [debug] mod_apreq.c(215): [client 127.0.0.1] apreq request is now initialized (135543824)
[Wed Oct 22 09:45:27 2003] [debug] mod_apreq.c(234): [client 127.0.0.1] apreq filter context created.
[Wed Oct 22 09:45:27 2003] [debug] mod_apreq.c(259): [client 127.0.0.1] prefetching 65536 bytes
[Wed Oct 22 09:45:27 2003] [debug] mod_apreq.c(365): [client 127.0.0.1] (70008)Partial results are valid but processing is incomplete: entering filter (1)
[Wed Oct 22 09:45:27 2003] [debug] mod_apreq.c(431): [client 127.0.0.1] leaving filter (1)
[Wed Oct 22 09:45:27 2003] [debug] mod_apreq_proxy_test.c(84): [client 127.0.0.1] loc = http://www.apache.org/
[Wed Oct 22 09:45:27 2003] [debug] proxy_http.c(109): proxy: HTTP: canonicalising URL //www.apache.org/
[Wed Oct 22 09:45:27 2003] [debug] mod_apreq.c(311): [client 127.0.0.1] dropping stale apreq filter (135543800)
[Wed Oct 22 09:45:27 2003] [debug] mod_proxy.c(459): Trying to run scheme_handler
[Wed Oct 22 09:45:27 2003] [debug] proxy_http.c(1076): proxy: HTTP: serving URL http://www.apache.org/%0A
[Wed Oct 22 09:45:27 2003] [debug] proxy_http.c(221): proxy: HTTP connecting http://www.apache.org/%0A to www.apache.org:80
[Wed Oct 22 09:45:27 2003] [debug] proxy_util.c(1203): proxy: HTTP: fam 2 socket created to connect to www.apache.org
[Wed Oct 22 09:45:27 2003] [debug] proxy_http.c(370): proxy: socket is connected
[Wed Oct 22 09:45:27 2003] [debug] proxy_http.c(404): proxy: connection complete to 209.237.227.195:80 (www.apache.org)
[Wed Oct 22 09:45:27 2003] [debug] mod_apreq.c(365): [client 127.0.0.1] entering filter (1)
[Wed Oct 22 09:45:27 2003] [debug] mod_apreq.c(393): [client 127.0.0.1] (70008)Partial results are valid but processing is incomplete: returning 8192 bytes from spool
[Wed Oct 22 09:45:27 2003] [debug] mod_apreq.c(401): [client 127.0.0.1] removing filter(0)

At this point I don't have time to investigate further...

#if CONFIG_FOR_HTTPD_TEST

<Location /apreq_proxy_test>
   # ProxyPass http://httpd.apache.org/
</Location>

#endif

#define APACHE_HTTPD_TEST_TRANSLATE_NAME apreq_proxy_test_handler
#define APACHE_HTTPD_TEST_HOOK_ORDER APR_HOOK_REALLY_FIRST

#include "apache_httpd_test.h"
#include "apreq_params.h"
#include "apreq_env.h"
#include "httpd.h"

static int apreq_proxy_test_handler(request_rec *r)
{
    apreq_request_t *req;
    apr_table_t *params;
    char *loc;

    if (strcmp(r->uri, "/apreq_proxy_test") != 0)
        return DECLINED;

    req = apreq_request(r, NULL);
    params = apreq_params(r->pool, req);
    loc = apr_table_get(params, "loc");

    apreq_log(APREQ_DEBUG 0, r, "loc = %s", loc);
    if(loc) {
        r->filename = apr_pstrcat(r->pool, "proxy:", loc, NULL);
        r->handler = apr_pstrdup(r->pool, "proxy-server");
        r->proxyreq = PROXYREQ_REVERSE;
    }

    return DECLINED;
}

APACHE_HTTPD_TEST_MODULE(apreq_proxy_test);
-- 
--------------------------------------------------------------------------------
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/    F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'

Re: [BUG] mod_apreq & mod_proxy stalls POST requests

Posted by "Philippe M. Chiasson" <go...@cpan.org>.
     I. On Thu, 2003-10-23 at 00:45, Joe Schaefer wrote:
> Joe Schaefer <jo...@sunstarsys.com> writes:
> 
> > "Philippe M. Chiasson" <go...@cpan.org> writes:
> > 
> > > I believe I've encountered an interaction problem with mod_apreq and
> > > mod_proxy. 
> 
> [...]
> 
> Actually I don't think this matters here- in this circumstance 
> mod_apreq's prefetch code is causing and extra EOS bucket to appear.  

YES, exactly what I have encountered. After probing at it a bit more, it
became apparent that mod_apreq was generating a filter flow with 2 EOS
buckets.

> I should have this repaired soonish.

Great!

-- 
--------------------------------------------------------------------------------
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/    F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'

Re: [BUG] mod_apreq & mod_proxy stalls POST requests

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes:

> "Philippe M. Chiasson" <go...@cpan.org> writes:
> 
> > I believe I've encountered an interaction problem with mod_apreq and
> > mod_proxy. 
> > 
> > I basically have to proxy certain requests to different locations
> > based on incoming arguments. This works as long as you make GET
> > requests. If I read the POST data early with apreq (translate_name
> > phase) and subsequently trigger a proxy request, mod_proxy 
> > somehow gets stuck trying to read data from the client.
> 
> [...looks good from the apreq side...]
> 
> > At this point I don't have time to investigate further...
> 
> If you get some time, try fixing these lines in proxy_http.c:
> 
> 689:        /* We can't pass this EOS to the output_filters. */
> 690:        APR_BUCKET_REMOVE(APR_BRIGADE_LAST(input_brigade));
> 
> Composing ring macros like that is a big boo-boo.

Actually I don't think this matters here- in this circumstance 
mod_apreq's prefetch code is causing and extra EOS bucket to appear.  
I should have this repaired soonish.

-- 
Joe Schaefer


Re: [BUG] mod_apreq & mod_proxy stalls POST requests

Posted by Joe Schaefer <jo...@sunstarsys.com>.
"Philippe M. Chiasson" <go...@cpan.org> writes:

> I believe I've encountered an interaction problem with mod_apreq and
> mod_proxy. 
> 
> I basically have to proxy certain requests to different locations
> based on incoming arguments. This works as long as you make GET
> requests. If I read the POST data early with apreq (translate_name
> phase) and subsequently trigger a proxy request, mod_proxy 
> somehow gets stuck trying to read data from the client.

[...looks good from the apreq side...]

> At this point I don't have time to investigate further...

If you get some time, try fixing these lines in proxy_http.c:

689:        /* We can't pass this EOS to the output_filters. */
690:        APR_BUCKET_REMOVE(APR_BRIGADE_LAST(input_brigade));

Composing ring macros like that is a big boo-boo.

-- 
Joe Schaefer