Re: updated findings on whenToUseGet

----- Original Message -----
From: "Larry Masinter" <LMM@acm.org>
To: "'Dan Connolly'" <connolly@w3.org>
Cc: <www-tag@w3.org>
Sent: Saturday, May 18, 2002 12:15 PM
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.

No such assumption is made as far as I can see.
I take Dan's writing of this to apply to GET as she is currently defined,
with any parameters encoded in the URI.

GET-with-body is not defined.
If it were defined, then presumably it would be defined which that the
effective URL included the body.
As Dan's draft mentions, "A QUERY or "safe POST" or "GET with BODY" method
has been discussed (e.g. Dec 1996 IETF meeting) but no consensus has
emerged."

Tim

>
> >    * 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 Thursday, 23 May 2002 10:51:43 UTC