Richard Lynch wrote:

>>>The problem is this redirection is being done with the GET method, so 
>>>all query string will be shown. How can I make this redirection use the 
>>>POST method?
>>You can't. This "redirection" is just a way of informing the browser 
>>that it needs to to to the location identified in the "Location" header 
>>to receive the content it desires. Even if a POST method was used in the 
>>request, the GET method will be used in all 300 range responses.
>I don't even know what you're trying to say here...
>But I don't think any of the 3xx responses give a damn whether it's GET or
>POST data coming in a priori.  Not saying you couldn't hack your PHP or your
>server to do something different and return something other than 3xx based
>on a GET or POST request, mind you.

I think you're confused about the series of events that occur here. 
We're talking about 3 different HTTP messages:
1) initial HTTP request
2) server's HTTP response
3) client's second HTTP request send in response to receiving a 
300-level status code in the response

It is correct that message #2 can be a 300-level response regardless of 
the request method used in message #1. However, it is false to say that 
something in message #2 can force the browser to use the POST method for 
message #3.

>>>Anybody know of an easy hack? I know there is a way but that requires me 
>>to re-compile PHP , which I 
>>>cant do.
>>I'm guessing the "way" you speak of is having the server do the POST 
>>itself using a PHP extension. This isn't the same thing. You can't 
>>exactly *force* the browser to submit a POST request. It's a good thing. :)
>And this is patently false.

Actually, this is correct.

>You send the right data to a web-server, and it looks like a POST, and
>that's what you got.
>Spew that out to the browser, and there it is...  Oh.  Okay, no, the
>Location bar will still show your URL, not the destination URL.  I see what
>you mean...

I think you're confused this time about the entities involved. We are 
speaking of two entities:
1) Web server
2) Web client

Who is the "you" in, "You send the right data to a web-server"?

>I think the guy just wants the POST data and doesn't care what the user sees
>in the Location box...  If I'm wrong on that score, apologies all around :-)

It appears that he wants to be able to issue a "Location" header that 
includes some data without having that data show up in a URL. To get 
around this, he (rightly so) looked into seeing if he can force the Web 
client to issue a POST request in response to the 300-level status code 
rather than the GET request. However, this is not possible.

>POST is no more secure, no more "tricky" and no more magical than GET.  It's
>just that any idiot can see the URL in their browser and figure out GET, and
>you have to actually read some documentation to figure out POST.  But it
>really ain't any different when you start looking at it from the perspective
>of making the web-server turn over and do tricks.

Here is a better description of the differences between POST and GET. I 
think it will help you.



PHP General Mailing List (
To unsubscribe, visit:

Reply via email to