I am writing a program that needs to process form data, (here's
the kicker) which is sometimes multipart/form-data, then
redirect a user to a GET request (which doesn't need to process
the form data). I would like to use the standard mechanism for
issuing a redirect, for other reasons:
$r->header_out('Location' => $url);
return REDIRECT;
I have discovered two ways to achieve redirects from a POST
request if its content is application/x-www-form-urlencoded:
- $r->print() the headers manually and have the handler return
DONE or HTTP_OK. This nasty hack is what I am doing at this
time so I can get redirects from multipart/form-data to
somehow work.
- convert the POST request to a GET and redirect the standard
way. I don't understand why forcing a read of all the data
coming in from the HTTP request allows redirects to work, but
it does.
When I do neither, i.e., leave the POST request as is and use
the standard redirect mechanism, the browser hangs and the
server actually does not send the redirect until I hit the Stop
button (I'm using ngrep to determine this). This also happens
if I use the $r->print($header) method and still return
REDIRECT.
The second method allows me to revert to the use of the default
redirect mechanism, but unfortunately does not work with
multipart/form-data. I would *really* like to be able to use
the standard redirection mechanism for other reasons. From the
Apache man page:
$r->content
The $r->content method will return the entity body
read from the client, but only if the request content
type is `application/x-www-form-urlencoded'.
...
Is there a similar technique I can use to read all the
multipart/form-data from the socket and then allow CGI.pm to
continue to process it, and would this work?
Thank you,
Darren
--
Darren Stuart Embry. Kicking down some kind examples of how to keep
your karma clean. http://www.webonastick.com/
``I base most of my fashion taste on what doesn't itch.''
--- Gilda Radner
