My apologies for continuing this topic, but I've been thinking some more
about this issue over the weekend. I'm still perplexed by this seemingly
arbitrary limitation on the number of times a request body can be read. It
seems that, at least theoretically, it should be possible to cache the
result of $r->content() or even $r->read() the first time it's called and
return the cached data on subsequent calls. It should also be possible to
have $r->read return the cached data even when called from an internal
redirect (by delegating calls to $r->prev->read, etc). As the size of a
request body can be arbitrarily large (e.g. file uploads), perhaps it would
be better not to have the caching behavior turned on by default, but rather
enable it on a per-request basis.
Again, this is all hypothetical. Can anyone comment on feasibility (and
usefulness) of such a feature?
Cheers
Dmitry
> > 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.
>
>But if you set $r->args to what you read from $r->content before
>redirecting, won't that work?
