updated findings on whenToUseGet

I updated the finding w.r.t. 5May discussion.

Chris, I still need some text from you about
the I18N situation.


--- ,get11.txt	Fri May 17 15:14:44 2002
+++ ,get7.txt	Fri May 17 15:14:53 2002
@@ -5,13 +5,21 @@
 ref. issue whenToUseGet-7

-DRAFT by Dan Connolly, for the TAG
-$Revision: 1.11 $ of $Date: 2002/05/01 21:30:59 $ by $Author: connolly $
+DRAFT by Dan Connolly, for the TAG. in progress: update w.r.t. 5May discussion
+$Revision: 1.12 $ of $Date: 2002/05/17 20:06:35 $ by $Author: connolly $

 Two principles are central to the design of Web sites and applications:
   * All important resources should be identifiable by URI.
+    In particular
+      + using GET for safe operations (read, query, view, ask, lookup, ...) on
+        HTTP resources makes them identifyable by URI, while using POST does
+        not
   * Following references in the web is safe; i.e. agents do not incur
     obligations by following links
@@ -96,7 +104,7 @@
 links; only that the obligations must be accepted some other way than
 requesting to follow a link.
-For confidential materials, a straightforward design is:
+Obligations of confidentiality can be established straightfowardly as follows:
  1. The client requests access to the materials
  2. The server declines, with an "authorization required" notice, and a link to
@@ -132,7 +140,21 @@
 for subsequent access to the same information, e.g., using Content-Location, is
-Myths and transitional limitations
+The case of large parameters to a safe operation is not directly addressed by
+HTTP as it is presently deployed. A QUERY or "safe POST" or "GET with BODY"
+method has been discussed (e.g. Dec 1996 IETF meeting) but no consensus has
+WebDAV (RFC 2518) uses a different HTTP method, PROPFIND (section 8.1 PROPFIND
+), for querying properties of resources; unfortunately, this provides no URI
+for the results of these queries..
+Myths, Bugs, and Ephemeral Limitations
+While Web application design must take into account the limitations of
+technology that is widely deployed at present, it should not treat these as
+architectural invariants. Some limitations are likely to fade away as bugs are
+fixed and the scope of interoperable specifications expands.
 Myth: search services won't index anything with a ? in the URI anyway
     This was a heuristic to avoid infinite loops in some search service
@@ -144,8 +166,11 @@
     generally at least 4000 characters, and they evolve as the legitimate uses
     of application developers evolve.
-Designers of HTML forms that accept non-western characters have been challenged
-by various implementation limitations and gaps in specifications. For example:
+Work to do
+[@@Chris, help here!] Designers of HTML forms that accept non-western
+characters have been challenged by various implementation limitations and gaps
+in specifications. For example:
     The content type "application/x-www-form-urlencoded" is inefficient for
     sending large quantities of binary data or text containing non-ASCII
@@ -154,6 +179,26 @@
 We expect these limitations to be address in future specifications (@@e.g.
 XForms?) and deployed in due course.
+The use of HTTP for typical safe remote operations is not addressed by SOAP
+specifications as of this writing:
+    HTTP Method: POST (the use of other HTTP methods is currently undefined in
+    this binding).
+    section Requesting State of SOAP Version 1.2 Part 2: Adjuncts,
+    W3C Working Draft 17 December 2001
+Intitial investigations into requirements and a proposed solution (SOAP HTTP
+GET Binding Version 0.1, Orchard, May 2002) suggest this limitation is
+straightfoward to address; meanwhile, "the oft-quote stock quote example" (
+Overview section) is misleading, since it suggest that HTTP POST is appropriate
+for this safe operation.
+WSDL 1.1 provides a binding to HTTP GET, which makes it possible to respect the
+principle of using GET for safe operations, but to more straightforwardly
+represent safety, it should be a property of operations themselves, not just a
+feature of bindings.
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Friday, 17 May 2002 16:41:27 UTC