Re: [Uri-review] Re: The 'javascript' scheme

* Graham Klyne wrote:
>A practical consequence of this approach would be, I think, is that, taking into
>account []
>(specifically:  "Principle: Safe retrieval - Agents do not incur obligations by
>retrieving a representation."), some restrictions should be placed on the kinds
>of Javascript that are acceptable in a javascript: URI -- specifically, not
>allowing Javascript with side effects visible outside the browser or application
>in which they may be used.  For example, a Javascript URI should not invoke any
>functions that update publicly visible data file systems or perform HTTP PUT or
>POST operations.  This requirement would go beyond normal security constraints
>for browser-side Javascript, as a URI can be used in all manner of contexts
>other than a browser.

I think such restrictions would be unreasonable, there is no difference
in this regard between using a hyperlink with a javascript:... URI that
triggers a POST request and a hyperlink with a onclick='...' script to
the same effect. Besides, the content retrieval operation defined in the
draft is essentially free of side-effects; I don't think performing the
in-context evaluation operation is "retrieving a representation". It is
probably true that one should not make HTML documents like

  <body onload='document.getElementById("form").submit()' ...
    <form id='form' method='post' action='http://...' ...

where the browser would perform a POST request automatically when the
document has finished loading, just as one might argue that regardless
of whether this is a bad practise, browsers should consult the user
before actually performing the POST request, but these issues apply to
scripting generally, and less so to the 'javascript' scheme.
Björn Höhrmann · ·
Weinh. Str. 22 · Telefon: +49(0)621/4309674 ·
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · 

Received on Sunday, 19 November 2006 02:01:35 UTC