On Wed, 2006-02-01 at 13:10 -0500, Ben Scott wrote: > On 2/1/06, Python <[EMAIL PROTECTED]> wrote: > > However, some forms become irrelevant depending upon the responses. In > > that case, the irrelevant form(s) are skipped and the next usable form > > is presented. However, the URL displayed in the browser came from the > > last form action and shows the URL for the first skipped screen. > > So send an HTTP redirect to the URL you want. > > > Using a Location header with status 302, 303 forces a GET (not a POST) > > to the new location ... > > Yup. That's what an HTTP redirect does, and it's what you're asking for. > :-) > > Unless you're asking for "Load one URL, but display a different URL > in the location bar, even though that URL is never loaded."
Status 201 with a Location header seems to fit this description, but does not change the display. > One major > problem with *that* is that phishing attacks want to do the exact same > thing. So if you find a way to do it, I recommend submitting it as a > bug to the Mozilla project and have them fix it so you can't do it. > Seriously. Well changing the path within a host is all I'm looking for, so it would not be quite like changing crooks.org into yourbank.com. > > > I do not want to do the necessary programming to support GETs. > > GET and POST basically do the same thing, and most toolkits abtract > the difference away anyway. There really shouldn't be any programming > differences. If there are, my first feeling would be, "Find a better > toolkit". :) The GET does not include the form variables. Aha. You are suggesting that I stuff the form variables into the location URL. Then the GET would include the variables. It would be an ugly looking URL, but the path part would match the form. > > > (The site management has a policy against cookies, and I can't think of > > any other way to maintain a session through a GET.) > > Well, the unmitigated fear of cookies is somewhat irrational. > However, the fact remains that some people refuse to allow them under > any circumstances, so one sometimes has to program around the problem. > > So: Rather then tracking state in a cookie, track it in a form > variable. Said form variable can be submitted via GET or POST. The state is in the form variables. The problem is (was - see above) getting the browser to include them in a GET request. Thanks for the enlightenment. > > -- Ben > _______________________________________________ > gnhlug-discuss mailing list > gnhlug-discuss@mail.gnhlug.org > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss -- Lloyd Kvam Venix Corp _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
