[whatwg] Updating Location Bar for RPC Type Apps

[Brad Neuberg]

Whenever I implement a DHTML (Ajax?) type app that needs to talk to the 
server without refreshing the client, such as through a hidden iframe or an 
XmlHttpRequest object, I always wish that I could update the window 
location bar to show a bookmarkable and copyable URL, but update it in such 
a way that it _doesn't_ refresh the browser or change it's location 
(window.location.href changes the location).

For example, lets say I am showing a page that has a table of elements on 
it, with a sorting pulldown that can change the sorting of the elements 
either by NAME or by a TAG sorting scheme.  Let's say the URL show in the 
location bar when the user first hits this page is the following:

http://www.rojo.com/manage-subscriptions

This page has a sorting pull down with two options, sort by NAME and sort 
by TAG.  When the user selects the TAG pulldown we shoot off a request 
through a hidden iframe, which travels to the server.  The server then 
generates new table content as HTML and sends it basic in the background, 
and the client simply does an innerHTML on a div in the center of the page 
with the new sorting type.

However, the URL in the location bar stays as 
"http://www.rojo.com/manage-subscriptions", when I would like it to update 
to "http://www.rojo.com/manage-subscriptions?sortby=TAG", so that a user 
can bookmark it, email it, or a programmer can see what the URL is in a 
clear way and can script it using HTTP (REST?).

Now we would have to be careful or this could lead to phishing attacks, 
where someone could update the URL arbitrarily.  We would have to enforce 
the same-host rule on the URL, the same rule that is applied to where an 
XmlHttpRequest object can communicate to (i.e. same host, same protocol, 
same port, etc.)

This also ties in with an earlier email I sent out about controlling the 
history/back-button as well.  In this case if the user hits the back button 
they actually _dont_ get anything we've sent through the iframe, when I 
want to plug these things into the history.  If we make it possible for 
programmers to control whether a remote URL sent through XmlHttpRequest is 
placed into the history or not I think we should think through the 
security, phishing, and general annoyance factors this could cause (imagine 
pushing hundreds of entries into the history, so that a user can't hit the 
back page to their original page to keep a user on the current page).

In fact, we should do a security, phishing, and annoyance scan (blink tag 
anyone?) over the WHAT-WG draft itself sometime, forming a threat model 
before so we know what potential attackers would actually be trying to 
do.  When we take this into account we should remember that sometimes email 
programs embed the browser into themselves, so that WHAT standards could be 
embedded into email messages, leading to various kinds of attacks and 
general wierdness.

Brad Neuberg




Brad Neuberg, bkn3 at columbia.edu
Senior Software Engineer, Rojo Networks
Weblog: http://www.codinginparadise.org

=====================================================================

Check out Rojo, an RSS and Atom news aggregator that I work on.  Visit 
http://rojo.com for more info. Feel free to ask me for an invite!

Rojo is Hiring!  If you're interested in RSS, Weblogs, Social Networking, 
Java, Open Source, etc... then come work with us at Rojo.  If you recommend 
someone and we hire them you'll get a free iPod!  See 
http://www.rojonetworks.com/JobsAtRojo.html.