Re: Actions (methods) must not appear in URIs
hi roy, but how i see the current design of (micro)sling - there is not any intention of 'storing' actions in the uri. of course a user can still code some 'actions' in his script - but this would not be the fault of sling. the 'selectors' are primarily used to resolve to a different 'view' of the content, or to pass additional render information, e.g. the dimensions of a resized image. i completely agree with toby. i see selectors exclusively as a means to display the same logical content in different ways for example: as html, as pdf, as a small navigation-images, as an html teaser in a list, etc... generally, i think that selectors are generally only relevant for GETs anyway. from what i can see there is absolutely no intention to put http methods into a selector. i think we never did that, and i am 100% with you that this would be bad design. is there anything in particular that makes you think that there is a danger that this would happen in (micro)sling? maybe we were not able to articulate the intention of the script mapping when it comes to methods and selectors properly... regards, david
Re: Actions (methods) must not appear in URIs
Hi Roy, Thanks for the clarification and links - comments inline. On 10/15/07, Roy T. Fielding [EMAIL PROTECTED] wrote: ...The original Web design notes forbid the use of GET for any action that is considered to have side-effects, because such an implementation allows users to be tricked into performing actions that they cannot anticipate... If we want to go the extra mile in Sling, we could wrap the JCR Session to make it read-only when processing GET (or HEAD) requests. That's not totally trivial as we'd have to wrap the Item, Node and Property as well, but that might help in avoiding GET abuse. ...The most common workaround for broken browsers (used only after an initial request using the real method fails) is to use a POST request (known unsafe) and include the real method in a header field called X-HTTP-Method-Override or X-Method-Override Dumb clients (say a mobile phone browser) often make it hard to add custom HTTP headers to form submissions. What would you recommend in this case? Using a POST which specifies the actual method as a parameter, as a second workaround in case the above one is not possible? ...If Sling is going to claim to be a RESTful framework, it must protect the original design goals and obey the separation of concerns within the generic interface of HTTP. And that applies equally to any software we build on top of Sling Totally agreed about Sling itself, and your vigilance is appreciated. About software that people build on top of Sling, I think the best we can do is to try to educate users in a gentle way, by providing best practices examples and utilities (like SLING-53). -Bertrand
Actions (methods) must not appear in URIs
I seem to have failed to get my point across when I last visited Basel and we talked about what can and cannot be done in a selector. The original Web design notes forbid the use of GET for any action that is considered to have side-effects, because such an implementation allows users to be tricked into performing actions that they cannot anticipate. http://www.w3.org/DesignIssues/Axioms.html#state REST requires that identification (via URI) be independent within the generic interface of Methods applied via messages, since failure to maintain that separation means that intermediaries will cause unanticipated actions to be applied that are unsafe. HTTP/1.1 (RFC 2616) states: 9.1.1 Safe Methods Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered safe. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. 9.1.2 Idempotent Methods Methods can also have the property of idempotence in that (aside from error or expiration issues) the side-effects of N 0 identical requests is the same as for a single request. ... And the URI spec (RFC 3986) says: 1.2.2. Separating Identification from Interaction A common misunderstanding of URIs is that they are only used to refer to accessible resources. The URI itself only provides identification; access to the resource is neither guaranteed nor implied by the presence of a URI. Instead, any operation associated with a URI reference is defined by the protocol element, data format attribute, or natural language text in which it appears. Even the HTML 2.0 spec (RFC 1866) said: If the processing of a form is idempotent (i.e. it has no lasting observable effect on the state of the world), then the form method should be `GET'. Many database searches have no visible side-effects and make ideal applications of query forms. ... If the service associated with the processing of a form has side effects (for example, modification of a database or subscription to a service), the method should be `POST'. In other words, if a selector is used to indicate a desired action (or, in general, if any part of a URI is allowed to contain an action that would override the role of METHOD in HTTP), then the software violates three Internet standards, TimBL's original design, and my formalization of the REST architectural style. The reason for such repeated mentions of this same requirement, over and over, is because every time such a wrong-headed application of the Web has been exposed on the Internet it has resulted in mass customer data loss and ensuing lawsuits. EVERY TIME. The Web was intentionally designed to allow robots and anticipatory browsing techniques (link prefetching, caching, etc.) to proceed based on the presence of a URI within a GET context. That's the way it is supposed to work. Obviously, we did not anticipate that browser authors would make it difficult to use the other HTTP methods when appropriate. The most common workaround for broken browsers (used only after an initial request using the real method fails) is to use a POST request (known unsafe) and include the real method in a header field called X-HTTP-Method-Override or X-Method-Override, e.g. http://code.google.com/apis/gdata/basics.html#Updating-an-entry http://mail-archives.apache.org/mod_mbox/incubator-abdera-commits/ 200702.mbox/[EMAIL PROTECTED] I don't *like* this solution, since it still provides a route around what should be legitimate firewall intermediaries that block specific methods, but I understand the need for it. Moreover, it is far less dangerous than placing actions within any part of the URI (where they are invoked by GET). In any case, actions within URIs is the most anti-REST thing possible. In addition to causing the unanticipated action-effects described above, they force the hypertext to be tightly-coupled to the server framework, which loses much of the coupling-free effects of the architectural style. I would be compelled to piss on any software that did such a horrible thing (and have done so many times in the past).
Re: Actions (methods) must not appear in URIs
thanks for this clarification. but how i see the current design of (micro)sling - there is not any intention of 'storing' actions in the uri. of course a user can still code some 'actions' in his script - but this would not be the fault of sling. the 'selectors' are primarily used to resolve to a different 'view' of the content, or to pass additional render information, e.g. the dimensions of a resized image. regards, toby On 10/15/07, Roy T. Fielding [EMAIL PROTECTED] wrote: I seem to have failed to get my point across when I last visited Basel and we talked about what can and cannot be done in a selector. The original Web design notes forbid the use of GET for any action that is considered to have side-effects, because such an implementation allows users to be tricked into performing actions that they cannot anticipate. http://www.w3.org/DesignIssues/Axioms.html#state REST requires that identification (via URI) be independent within the generic interface of Methods applied via messages, since failure to maintain that separation means that intermediaries will cause unanticipated actions to be applied that are unsafe. HTTP/1.1 (RFC 2616) states: 9.1.1 Safe Methods Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered safe. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. 9.1.2 Idempotent Methods Methods can also have the property of idempotence in that (aside from error or expiration issues) the side-effects of N 0 identical requests is the same as for a single request. ... And the URI spec (RFC 3986) says: 1.2.2. Separating Identification from Interaction A common misunderstanding of URIs is that they are only used to refer to accessible resources. The URI itself only provides identification; access to the resource is neither guaranteed nor implied by the presence of a URI. Instead, any operation associated with a URI reference is defined by the protocol element, data format attribute, or natural language text in which it appears. Even the HTML 2.0 spec (RFC 1866) said: If the processing of a form is idempotent (i.e. it has no lasting observable effect on the state of the world), then the form method should be `GET'. Many database searches have no visible side-effects and make ideal applications of query forms. ... If the service associated with the processing of a form has side effects (for example, modification of a database or subscription to a service), the method should be `POST'. In other words, if a selector is used to indicate a desired action (or, in general, if any part of a URI is allowed to contain an action that would override the role of METHOD in HTTP), then the software violates three Internet standards, TimBL's original design, and my formalization of the REST architectural style. The reason for such repeated mentions of this same requirement, over and over, is because every time such a wrong-headed application of the Web has been exposed on the Internet it has resulted in mass customer data loss and ensuing lawsuits. EVERY TIME. The Web was intentionally designed to allow robots and anticipatory browsing techniques (link prefetching, caching, etc.) to proceed based on the presence of a URI within a GET context. That's the way it is supposed to work. Obviously, we did not anticipate that browser authors would make it difficult to use the other HTTP methods when appropriate. The most common workaround for broken browsers (used only after an initial request using the real method fails) is to use a POST request (known unsafe) and include the real method in a header field called X-HTTP-Method-Override or X-Method-Override, e.g. http://code.google.com/apis/gdata/basics.html#Updating-an-entry http://mail-archives.apache.org/mod_mbox/incubator-abdera-commits/ 200702.mbox/[EMAIL PROTECTED] I don't *like* this solution, since it still provides a route around what should be legitimate firewall intermediaries that block
