http / browser help: changing url in location window
Ben Scott
dragonhawk at gmail.com
Wed Feb 1 15:41:01 EST 2006
On 2/1/06, Python <python at venix.com> wrote:
>> 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.
Hmmm. Interesting. I've never used (or even, I think, encountered)
HTTP 201 before. Reading the spec, it would seem to imply that it
might work like an HTTP redirect. As I read it, the entity actually
returned with the HTTP 201 should basically be a "redirect page"
telling people where to go, just like is often seen with HTTP 302.
You'd still end up with the problem of the browser likely doing a GET
on the newly-created resource, loosing all your state.
I suspect what is happening is that Firefox is treating the HTTP 201
to be like an HTTP 200, and ignoring the "Location" header entirely.
Same situation as with early browsers before HTTP redirect was
invented encountering a modern server -- you get the "Click here if
your browser doesn't catch on" sort of page.
>> 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.
Okay, you have a point there, but I still very much don't like the
idea of the page I'm seeing not being the URL I'm seeing.
> 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.
Exactly.
Optionally, you can make the URL somewhat less ugly by using a
simple session ID and tracking the rest of the state on the
server-side.
> The state is in the form variables. The problem is (was - see above)
> getting the browser to include them in a GET request.
The only other thing I can think of would be to embed some
JavaScript in the returned response to the initial POST that redirects
the browser with a new POST to a different URL. But that's nightmare
in itself, and way worse then cookies.
I can also think of some other things that don't solve the problem
per se, but offer alternate approaches:
1. Use the same URL for all stages of the survey, and detect the stage
of the survey in code using a form variable.
2. Don't worry about what the URL looks like at all. It's a silly detail. :)
-- Ben "I've wasted hours on sillier details" Scott
More information about the gnhlug-discuss
mailing list