RE: draft findings on Unsafe Methods (whenToUseGet-7)

I am sending this to the wsawg and dist-app lists in addition to the TAG
list.  This issue was actively debated on the April 15th TAG call.

1. I believe the wording on TAG issue whenToUseGet-7 is somewhat flawed.  I
could live with any of :
 a. safe methods (GET/HEAD) should be used for safe operations in
browser-centric applications
 b. safe methods (GET/HEAD) *may* be used for safe operations or
 c. safe methods (GET/HEAD) should be used for safe operations in web
applications that are information oriented.

My concern is that the web services world is almost universally built upon
the use of HTTP POST when used with HTTP for document exchange, and this
finding may imply that exclusive use of the SOAP HTTP Binding (particularly
POST) is a violation of the web, and may need correction.  Certainly when I
brought this up in the TAG call, various people were wanting to change web
services to do the "right" thing in their mind.

My belief is that the web has been based upon a shared information space,
primarily through use of GET/POST methods.  However, as we move towards more
machine to machine oriented communications, with arbitrary payloads of XML,
and it's focus on update/service oriented architectures, the need for a
public contract for safe actions is dramatically reduced.  Indeed the
browser-centric web arbitrarily chooses GET or POST for various reasons that
are unrelated to safeness, but more because of browser characteristics and
server implementation decisions.  There are many cases of safe POSTs and
unsafe GETs.

My personal position on the centrality of HTTP GET/POST to the web is
detailed in [1].  There have been many people that have posted on the
www-tag list on the centrality of HTTP GET, the issue of strong-typing,
relationship of SOAP to HTTP, and other closely related facets, such as Don
Box [2], Noah Mendelsohn [3], Henrik Nielsen [4], and others.

For these reasons, and others including the lack of consensus on this issue,
it is inappropriate to create issue resolution wording that could result in
suggestions that safe web services must use a new HTTP GET binding, that the
XMLP/WSDL/Web Services Architecture Groups should change probably
significant sections of their wording, to delay publication of SOAP 1.2 (in
order to do more work on a GET binding), or other charter/wording/schedule
changes.

I have strived for a middle ground, that of suggesting that GET usage is for
a particular application of the web - as opposed to a definitive
characteristic of the web - but mine and others arguments appear to have
been unpursuasive.  So...

2. I repeatedly suggested on the TAG call the creation of a liaison between
the TAG and some subset of the Web Services Activity be struck to deal with
the issue of Web Services interactions being typically POST based.  The TAG
did not decide for or against this proposal during it's call.  This was also
raised by HenrikN during the last WSAWG call.  I would like the WSACG to
take up the issue of requesting the setting up a WSA/TAG liaison during it's
next meeting.  The first task would be resolving the issue of HTTP POST vs
GET for web services use cases.  I might even be so bold as to suggest
looking at web services use cases that involve a priori knowledge of "safe"
interactions.  I think that the ws activity members probably have an opinion
on the issue of whether HTTP GET SHOULD be used for safe methods,
considering the current SOAP 1.2 HTTP binding.  Further, some members of the
TAG seemed quite interested in changing the web services architecture
instead of trying to documenting and achieve consensus on this issue.  I
refused a request to, in my words, "lead the charge in getting the WSA to do
the SOAP and WSDL changes to do the right thing".  This is a classic liason
activity, where we need to strive for consensus between different views.  I
would be glad to participate and help in such a liason.

3. I encourage interested parties in the other groups to respond to this
issue.  This is one of the first TAG findings, and has potential significant
ramifications to the web services architecture.  Formal - as suggested in
item #2 - and personal discussions - this item - should help foster
education and consensus that have so far been illusive.  I've specifically
sent this note to dist-app as a call to arms on this issue.

4. A personal note.  I find it disappointing that we are debating this
issue.  I would rather being doing what I consider more productive
forward-looking work, such as web service security
use-cases/requirements/charter or closing SOAP 1.2 issues, than debating a
technical decision that has shipped in many thousands of units and does not
have any consensus in the real world.  But there are such extremes of
opinion and desires for "correcting behaviour" rather than documenting
consensus that I and others will be forced to spend time on this issue.

Cheers,
Dave

[1] http://lists.w3.org/Archives/Public/www-tag/2002Mar/0259.html
[2] http://lists.w3.org/Archives/Public/www-tag/2002Mar/0177.html
[3] http://lists.w3.org/Archives/Public/www-tag/2002Mar/0082.html
[4] http://lists.w3.org/Archives/Public/www-tag/2002Mar/0201.html



> -----Original Message-----
> From: www-tag-request@w3.org
> [mailto:www-tag-request@w3.org]On Behalf Of
> Dan Connolly
> Sent: Monday, April 15, 2002 8:51 AM
> To: www-tag@w3.org
> Subject: draft findings on Unsafe Methods (whenToUseGet-7)
>
>
> This got some discussion in today's telcon,
> but folks haven't really had a chance to read it;
> I'm trying to figure out whether I'm mostly
> done and should just polish off the few remaining
> @@TODOs, or whether the essential guts need work.
>
>
>   DRAFT Findings on Safe Methods
>   on issue whenToUseGet-7
>
>   DRAFT by Dan Connolly, for the TAG
>   $Revision: 1.5 $ of $Date: 2002/04/15 14:26:17 $ by
> $Author: connolly
> $
>
>   http://www.w3.org/2001/tag/doc/get7
>
>
> text copy:
>
> --8<--
>  A great deal of the utility of the Web depends on the
> ability of users
>    (and agents) to explore the shared information space safely; to
>    explore a page and come back, without channging anything. A very
>    important principle when designing Web applications is:
>      * safe methods (GET/HEAD) should be used for safe
> operations: read,
>        query, view, ask, lookup
>      * safe methods must not be used for unsafe operations: write,
>        update, modify, tell, buy, agree
>
>    Though the principle applies to ftp (CHDIR and RETR are
> safe; PUT is
>    not) and other protocols, most Web applications are built
> using HTTP;
>    it is critical to build these applications with an awareness of the
>    following section of the HTTP specification:
>
>      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.
>
>
>     [4]9.1.1 Safe Methods, HTTP 1.1
>
>       [4]
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1
>
>    It is also very important to keep this principle in mind when using
>    HTML forms:
>
>      The "get" method should be used when the form is
> idempotent (i.e.,
>      causes no side-effects). Many database searches have no visible
>      side-effects and make ideal applications for the "get" method.
>
>      [5]17.13.1 Form submission method of HTML 4.01 (text has been in
>      HTML spec back to [6]HTML 2.0)
>
>       [5]
> http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.
> html#h-17.13.1
>       [6] http://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2.2
>
> Applications that depend on safe methods
>
>    A wide variety of applications depend on the safety
> property of HTTP
>    GET:
>      * search service crawlers
>      * caching proxies
>
>    not to mention the importance of the ability of users to explore
>    safely. (@@cite stats about the popularity of the back button)
>
> Example: mailing list subscription
>
>    Consider the following two designs for mailing list subscription
>    confirmation; in the first case:
>     1. The user sends a subscribe message to an administrative mailbox
>        (mylist-request@example.org).
>     2. The list processing software requests confirmation by email,
>        including a link to a confirmation page
>     3. The user visits the confirmation page, and finds a "[Confirm]
> your
>        subscription" form, with method="POST".
>     4. The user activates the [Confirm] form control.
>     5. The list processing software confirms the subscription.
>
>    In the second case:
>     1. as above
>     2. as above
>     3. The user visits the confirmation page and sees "your
> subscription
>        is confirmed". The list processing software confirms the
>        subscription.
>
>    The latter design performed an unsafe operation (list subscription)
> in
>    response to a request with a safe method (following the
> link from the
>    mail message with GET).
>
> --8<--
>
> --
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
>
>
>

Received on Monday, 15 April 2002 18:04:36 UTC