> I think that's just a coincidence. IIRC, the spec doesn't require this to > work, and it doesn't work in all browsers. The only real solution is to not > do it. PATH_INFO was a good suggestion. I'd go with that if it can't be > added to the POST data.
Thanks. I've taken your advice and am using a redirect after form submission to the original URL (the URL with the GET args I was using in the form 'action' attribute) as a workaround. I can't use PATH_INFO (or $r->path_info() ) because I submit forms via GET at various parts of the application so that users can bookmark the results (search results for example). Both browsers (IE and NS) seem to be submitting both a POST and GET request. In the case of the POST request, the GET params are included in the URL and both GET and POST params are accessable via $r->args() and $r->content respectivelly (provided it is the POST request you're processing and not the GET - and you can't be sure of which). I put a sniffer on the wire and the header of the GET and POST requests looks like so: POST /?step=10&search=Perl HTTP/1.1 GET /?step=10&search=Perl HTTP/1.1 (The POST request has the posted data included at the end of the header) So it seems that it depends which request is received first. In the case of netscape it's always the GET first and in the case of IE it is mostly the POST first but it varies.
