Yes, I'm with Andrei on this.  All I want to do is to peek at the content 
been passed and redirect the request based on what's in it.  I did see 
Doug's snippet in the archives, but I decided it didn't apply to me as it 
still wasn't offering a way to retain the content.

This limitation of calling Apache::content (or Apache::read for that 
matter) only once per request seems to be quite arbitrary (I understand the 
reason now, but I still think it's arbitrary).  I'm beginning to think, 
however, that the problem is rooted somewhere in the Apache API and has 
nothing to do with mod_perl, although I suspect that it should be possible 
to work around this limitation within mod_perl.

At 08:31 AM 10/8/99 , Eric Cholet wrote:
>But if you set $r->args to what you read from $r->content before 
>redirecting, won't that work?

Setting Apache::args is a nice work-around, but it won't work with file 
uploads or otherwise large POST requests (will it?).

So my next questions are:  1) is it somehow possible to stuff the result of 
the content/read call back into a request's body for an internal_redirect? 
2) if not, is this the kind of functionality other people would like to 
have? 3) If yes, can mod_perl be changed to implement this functionality or 
should this be brought up on an Apache list?

Thanks everyone

Dmitry

At 08:24 AM 10/8/99 , Andrei A. Voropaev wrote:
>Right :) You just missed the point. I want to read content
>(using $r->content) to check what is being passed and then redirect
>that same content to another handler. That new handler should be able
>to read it from some place. I fool it to believe that method is get
>not post, so it'll try to read $r->args. But it will also return empty
>string.
>
>On Fri, Oct 08, 1999 at 05:05:41PM +0200, Eric Cholet wrote:
> > On Friday, October 08, 1999 3:35 PM, Andrei A. Voropaev
>
> > > Well. I wish you have also mentioned how to unset $r->content()
> > > because it reads content only once. Second time returns undef. The
> >
> > But you shoudn't be radubg $r->content for a GET, right?
> >

Reply via email to