amk@amk.ca wrote: >>That would be ideal. I simply want to be able to specify "the 'id' >>paramater that came in via POST" as opposed to "the 'id' paramater that >>came in via GET". In PHP form variables are made available in two > > I'm unsure if this is really appropriate. A long time ago I tried to figure > out if the HTTP + HTML standards actually made this usage legal, and > couldn't parse that meaning out of the documents. Therefore I deliberately > wrote the parsing code so that it ignored the query string on POSTs. This > property of the Quixote code may have subsequently changed, whether > deliberately or not, but it still strikes me as dodgy practice and one that > should be avoided. I've never seen anything to support the idea that query string information should be ignored if a form has been POSTed. > Can we find an interpretation of the HTTP RFC which allows this usage? That > PHP supports this division, or that existing web browsers support it, isn't > really evidence one way or the other. I would argue that doing so is a fundamentally bad idea as you are throwing away information that has been sent to the server from the client without any specification having told you to throw that information away. No other server side technology I have seen has discarded query string information sent with POST requests, so the defacto standard in the absence of clarification from a specification would be to keep it. In looking through the HTTP specification while researching this issue, I did come across the following snippet which I think supports my desire to be able to distinguish between information sent by POST and GET: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1 """ In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe" """ How can you follow such a convention if you have no way of telling whether form information came in via POST or via GET? Thanks, Simon Willison http://simon.incutio.com/