- From: <noah_mendelsohn@us.ibm.com>
- Date: Sat, 18 May 2002 21:58:31 -0400
- To: <LMM@acm.org>
- Cc: "'Dan Connolly'" <connolly@w3.org>, www-tag@w3.org
I certainly can't speak for the workgroup, but it's my impression that most of those who have been involved in discussing this issue understand why GET with a resource-identifying body is not a solution. The whole purpose of any work on an HTTP/GET binding would be to ensure that URI's and GET are used in a manner consistent with both the letter and the spirit of the web architecture. Furthermore, I would expect that the tag still has the option to non-concur with whatever might be proposed by the XMLP group, so I would expect that we all have a shared interest in coming to a mutually agreeable solution. While I agree that your concern is legitimate, I'd be surprised if it were a problem in practice. Thanks very much. ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------ "Larry Masinter" <LMM@acm.org> Sent by: www-tag-request@w3.org 05/18/02 12:15 PM Please respond to LMM To: "'Dan Connolly'" <connolly@w3.org> cc: <www-tag@w3.org>, (bcc: Noah Mendelsohn/Cambridge/IBM) Subject: RE: updated findings on whenToUseGet The updated "finding" still seems to assume that "GET with body" has something to do with solving the problem of insuring that important resources should be accessible via a URL. But if the data to access the resource is in the body (or in any headers or anywhere other than the URL itself), then the goal isn't accomplished. There's no difference between POST and GET-with-body as far as accomplishing the stated objective. > * 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 Does not what? Maybe I am not reading your 'diff' notation correctly. > The content type "application/x-www-form-urlencoded" is > inefficient for > sending large quantities of binary data or text > containing non-ASCII It's not exactly right to talk about a 'content type' when encoding data in a URI. The awkward name 'application/x-www-form-urlencoded' was made up for creating a MIME body that is encoded using the URI mechanism, but for talking about the URI-encoding method, it's just the URI encoding method. > We expect these limitations to be address in future > specifications (@@e.g. XForms?) and deployed in due course. It's not in the XForms charter to solve this problem, I don't think.
Received on Saturday, 18 May 2002 22:16:43 UTC