[EMAIL PROTECTED] wrote:
> I've got a bit of a better grasp on the problem now....I think it's an
> interaction with POST data...
>
> I have a form in foo.html....
>
> <form action="/rms/admin" method=post>
> <input type=hidden name=task value=process_config>
> ...other form fields...
> </form>
>
> I submit this form, and in /rms/admin, it gets handled like this....
>
> # suck in form values, stick them in objects, blah blah, then get to the
> redirect...
> $r->internal_redirect('/rms/status?task=display');
>
> and what happens is that /rms/status complains that it doesn't know how to
> handle task=process_config. So, somehow the value for 'task' that was
> POSTed in the first request from the form gets passed onto the second
> request, apparently overriding the
> 'task' value of 'display' which I am trying to set in the url string I'm
> giving to internal_redirect().
you can only read POST data once, so once it's slurped from the main
request it's gone unless you store it someplace. for it to show up in
the internal redirect (outside of your object) you'd have to follow
the example of changing a POST to a GET and stuffing the POST data in
the query string (using something similar to recipe 3.18 and/or the
example in the Guide).
so, it sounds like your object is bleeding data over from the main
request into the redirect.
>
> I don't want any of the POST data to get passed onto that redirect.
it shouldn't be there. try reading from $r->content and $r->args in
the redirect and see what you find.
> Any
> thoughts? I saw a note in the API docs that $r->args() can be used to set
> the query string and that this is useful when redirecting POST requests. I
> tried doing a $r->args('task=display') right before the call to
> internal_redirect, but no luck.
setting $r->args in the main request won't bleed over either. I went
through the code for ap_internal_redirect yesterday and it definitely
takes the query string from the passed in URI.
HTH
--Geoff
