Re: internal_redirect and POST
Yes, I agree. But as (I thought) I had mentioned in an early post, it should be possible to turn on this caching behavior for each individual request before a call to $r-content or $r-read. Cheers Dmitry On 28 Oct 1999, Greg Stark wrote: That makes sense for small pieces of data such as might be posted by a browser from a typical form. But browsers doing a file upload could send huge amounts of data, possibly many megabytes. Trying to store all of it in memory would be a bad idea. Also, not every HTTP client is a web browser, some POST form submissions could be huge transactions even without a file upload. Dmitry Beransky [EMAIL PROTECTED] writes: 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.
RE: internal_redirect and POST
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?
Re: internal_redirect and POST
Dmitry Beransky [EMAIL PROTECTED] wrote: 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? This would be very nice, but looking through the source code for Apache last week, the socket connection is closely tied to it's idea of stdin for POST operations. I could not find a way to present the body of the request to arbitrary handlers. Hopefully Apache 2.0 can eliminate this problem with the layered I/O that I've heard rumors about. -- James Smith [EMAIL PROTECTED], 409-862-3725 Texas AM CIS Operating Systems Group, Unix
Re: internal_redirect and POST
On Fri, Oct 08, 1999 at 09:39:30AM +0200, Eric Cholet wrote:
On Friday, October 08, 1999 3:35 AM, Dmitry Beransky [SMTP:[EMAIL PROTECTED]] wrote:
I've been playing around with internal redirects of POST requests. They
seem to work fine as long as I don't call Apache::content() or any other
function that reads a request's content. However, as soon as I read it,
This has come up before. Try this (snippet courtesy DougM :-)
my $r = shift;
$r-method("GET");
$r-method_number(M_GET);
$r-headers_in-unset("Content-length");
$r-internal_redirect_handler("/new/url");
Well. I wish you have also mentioned how to unset $r-content()
because it reads content only once. Second time returns undef. The
same seems to be true for $r-read. As to $r-args it's not mentioned
in the book that you can call $r-args($new_query_string) to set new
query string. And if we do internal redirect then we usually need to
provide the content string for it.
Andrei
RE: internal_redirect and POST
On Friday, October 08, 1999 3:35 PM, Andrei A. Voropaev
[SMTP:[EMAIL PROTECTED]] wrote:
On Fri, Oct 08, 1999 at 09:39:30AM +0200, Eric Cholet wrote:
On Friday, October 08, 1999 3:35 AM, Dmitry Beransky
[SMTP:[EMAIL PROTECTED]] wrote:
I've been playing around with internal redirects of POST requests.
They
seem to work fine as long as I don't call Apache::content() or any
other
function that reads a request's content. However, as soon as I read
it,
This has come up before. Try this (snippet courtesy DougM :-)
my $r = shift;
$r-method("GET");
$r-method_number(M_GET);
$r-headers_in-unset("Content-length");
$r-internal_redirect_handler("/new/url");
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?
same seems to be true for $r-read.
If you use $r-content then you don't want to use r-read, right?
As to $r-args it's not mentioned
in the book that you can call $r-args($new_query_string) to set new
I suggest you complain to the book's authors :-) However I will update
Apache.pm's pod documentation which also doesn't mention this.
query string. And if we do internal redirect then we usually need to
provide the content string for it.
I don't know what we "usually" need to do for an internal redirect. I do
know that the symptoms you described have come up before, and I fished out
an answer from the archives.
I'm sorry I didn't provide a turnkey solution, but maybe my answer put you
on the right track?
Andrei
--
Eric
