Re: No consensus on draft findings on Unsafe Methods (whenToUseGet-7)

Larry Masinter wrote:
>>I propose that for those proportion of SOAP requests that consist of a
>>service name plus a sequence of name-value-pair arguments, we devise a
>>simple url encoding.  Wouldn't be hard.
> 
> Please make sure that the issues are addressed:
> 
> - length limits on URLs
>    Can the length be limited a priori? Or should the server
>    be required to support both GET and POST, and the client
>    allowed to send both?

Well, existing SOAP implementations support POST per definition,
so the proposal requires adding support for the urlencoded GET,
which seems pretty easy to me.

BTW, I've never had a web app break when GETting because the URL
was too long... my impression is that modern servers like Apache
and IIS basically don't care any more.  Section 3.2.1 of HTTP 1.1
doesn't give much help.

> - no standard encoding for non-ASCII
>    Unless the names and values in the name-value-pair arguments are
>    limited to ASCII only values, the simple URL encoding should specify
>    how encoding is handled.
> 
>    I guess the stock quote example is ASCII only. Otherwise
>     you use UTF-8 & hex encoding?

Yes, just like in section 4.2.2 of the XML spec.  I thought this was a
solved problem, or am I missing something?

> If you allow two encodings (one using GET when it works
> and one using POST when GET doesn't work for one reason
> or another), don't you add to the complexity of the
> implementations? 

Yes.  And you get the web-architectural benefits of GET.
Is it worth it?  Not sure.  But nobody would be required to
use the GET mechanism unless they thought the benefits of
caching and bookmarking and direct human access and so on
were worth the effort.  I still think the implementation effort
on the server side is trivial.

 >The 'S' in SOAP stood for 'Simple'.

Granted.  But the 'Web' in 'Web Services' presumably is the Web.
-Tim

Received on Monday, 22 April 2002 00:29:44 UTC