perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: [patch] C implementation of $r->content + rfc on the name
Date Mon, 19 May 2003 16:11:15 GMT
"Philippe M. Chiasson" <gozer@cpan.org> writes:

[...]

> Well, then what is the better solution if 2 different modules need
> access to the POSTed data (I didn't look at how apreq handles this) ?

In (the C API for) apreq-2, we inject a filter into the input chain.
It's essentially a passive "tee":


incoming POST data =>  [ap_http_filter] => ... 

                     ... => [apreq filter] => ... [content handler]
                                 |
                                 |
                                 v
                              [parser] -> [hook] -> apr_table
                                 
The filter is only injected once per-request, and the POST data should
available to any phase of the request.  For example, suppose an aaa 
handler needs apreq-2 to look for something in the POST data.  The 
apreq filter will first prefetch some (configurable) amount of the 
POST data, and then

  1) store the raw POST data in an internal brigade,
     so the actual content handler will be able to get it later on,

  2) send a copy of whatever it got to the parser, to honor
     the aaa handlers' request.

If apreq doesn't find what the aaa handler needs, the aaa handler can
repeat the process if it really wants to.  But it probably would be
better off to just reject (or decline) the request in such a case.

The current implementation of the apreq-2 filter isn't exactly problem
free at the moment (e.g. internal redirects are still messy), but I'm sure 
this is the right approach.

> I would many times over prefer users to use something similar to
> should_client_block(). But if enough users of mp _want_ to have
> $r->content, we need a _good_ way of achieving that (or a better excuse
> not to do it: "nevermind that, just use libapreq2 and it'll be even
> simpler/faster")

I don't have any objections to having $r->content in mp2; but
I do think it's a very bad idea to make it "too" smart.  By NOT
having it automatically stuff something in a request note,
you actually discourage people from abusing it (e.g. by attempting 
to use $r->content outside of the actual content-handler).

-- 
Joe Schaefer


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message