[go: up one dir, main page]

ACTION-353: Client-side identification in Ajax applications

This note is in fulfillment of TAG ACTION-353.  My intention here is to 
set down some thoughts on the relationship between section 2.3  of our 
finding on Metadata in URIs [1], and the client-side manipulation of URIs 
by AJAX applications (as partially explored in "Usage Patterns For 
Client-Side URL parameters " [2]).  Please read section 2.3 of [1] before 
proceeding with the rest of this note, as I will assume it as background.

Section 2.3 of the finding explains how an HTML form is in a sense a 
simple computer program, sent by the server to the client, that encodes 
knowledge of the assignment policy for a class of URIs;  for example, the 
form might give to the client the logic needed to fill in, and submit for 
processing, a class of URIs like this (example taken from the finding):

        http://example.org/cityweather?city=CityName

where the form logic encodes the ability to fill in specific values for 
the CityName.  The finding also says:

"Note that the example carefully specifies that the HTML form is sourced 
from the same authority as the individual weather URIs that the form 
queries. In fact, it is also common for the ACTION attributes in HTML 
forms to refer to URIs from other authorities. In such cases, it is the 
provider of the form rather than the assigning authority for the queried 
URIs who is responsible for the claims made in the form. In particular, 
users (and software) should check the origin of HTML forms before 
depending on the URI assignment patterns that they appear to imply. Of 
course, you can always use such a form to perform a query and see what 
comes back; what you can't do is blame the assignment authority if the 
generated URIs either don't resolve (status code 404) or return 
representations that don't match the expectations established when reading 
the form (you got a football score instead of a weather report). "


What I would now like to do is to suggest a parallel between the case of 
these HTML forms, and AJAX-style Javascript that does client-side 
manipulation of URIs.  I believe that the two cases are similar in at 
least the following ways:

1) Both the HTML form and the Javascript are "programs" sent from the 
server to the client
2) In both cases, the server is encoding into the program the server-side 
knowledge of the assignment policy for the URIs
3) In both cases, this "knowledge" in the client code can be considered 
authoritative >if< the server is acting on behalf of the assignment 
authority;  if Javascript sent from authority A does client-side 
generation of URIs assigned by authority B, then A is taking 
responsibility for using the B URIs correctly -- as noted in the finding, 
A cannot be responsible for mistakes in the program sent by B

So, with this background, we can consider the example of an Ajax mapping 
application, and explain with some rigor why it is that the client-side 
AJAX can generate and present to the user (e.g. for copy/paste or 
emailing) a variety of URIs that both the server and the client will 
understand as identifying maps centered on a particular location, with a 
certain zoom level, etc.:

1) We assume that the resource authority controls the server at 
http://maps.example.com and is also the provider of the mapping 
application served from such that server.
2) The authority decides to assign the class of URIs:   
http://maps.example.com?latitude=xxx+longitude=yyyy+zoom=zzzz.  When an 
HTTP GET is received for any of these URIs, the server responds with a 
representation of the map centered at {latitude,longitude} and zoomed to 
the requested level.  In the most interesting case, the server does this 
by sending to the client Javascript+HTML Ajax logic that will, initially, 
present the requested map.

Now consider that the user pans the map to a different location, or zooms 
it.  The user then requests from the Ajax application a URI that can be 
emailed, and that represents the new map location and zoom.

3) Just as the HTML form mentioned in [1] encodes the assignment 
authority's knowledge of the URI assignment policy, the Javascript at the 
client encodes map.example.com's policy for assigning URIs to map 
locations.  So, the URIs generated at the client are indeed traceable to 
the assignment authority, and just as in the HTML form case, we can 
explain why the same party is responsible for their consistent use at the 
client and the server.  Indeed, the server and the client share knowledge 
of this assignment policy;  either will present the correct map for this 
URI (the server would do this for an HTTP GET;  the client might do it 
locally when the BACK button is pressed, if sufficient information has 
been cached.)
4) As with the HTML form case, such client-side manipulation is more 
suspect in the case where the Javascript manipulates URIs that are from a 
different site (authority).  This is exactly parallel to the case of an 
HTML form from site (authority) A generating and submitting URIs from site 
B.  These may well be correct too, but it is A's responsibility to have 
correct knowledge of B's assignment policy, and to properly reflect it in 
the HTML Form or AJAX Javascript.

I think this is a good story that shows how an important aspect of 
traditional Web architecture extends directly to Ajax Web applications. I 
suggest we consider including an analysis like this in the next WD of the 
finding "Usage Patterns For Client-Side URL parameters " [2].

I think it's worth further distinguishing two cases:

Case A. The generated URIs are being used purely at the client, e.g. for 
putting on the history stack so the BACK/FWD buttons will work.  This case 
is of less interest, because in this case the URIs don't in general leak 
out from the client.  The client could probably get away with using a 
local policy that the assignment authority knew nothing about (as long as 
the client did not inadvertently push on the history stack a URI that was 
used by the server for a different purpose.)

Case B. As in the mapping example above, the client-generated URIs are to 
bookmarked, emailed, etc., and thus may later be presented to the server 
for dereferencing.

I think B is ultimately the more interesting case, and we should be sure 
to tell that story.

Noah


[1] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20070102.html#forms
[2] http://www.w3.org/TR/2009/WD-hash-in-uri-20090415/

Tracker: this relates to ISSUE-60

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Saturday, 6 March 2010 20:43:08 UTC