- From: Larry Masinter <LMM@acm.org>
- Date: Sat, 18 May 2002 09:15:56 -0700
- To: "'Dan Connolly'" <connolly@w3.org>
- Cc: <www-tag@w3.org>
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 12:16:43 UTC