http / browser help: changing url in location window

[Python]

On Wed, 2006-02-01 at 13:10 -0500, Ben Scott wrote:
> On 2/1/06, Python <python at venix.com> 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 at mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
-- 
Lloyd Kvam
Venix Corp