RE: Background information on GET and XForms (was: GET should be encouraged...)

Not speaking on behalf of any Working Group or person but me...

Yes.

For sending XML or multipart/form-data serialized instance data, GET makes
no sense.

For sending application/x-www-urlencoded instance data, GET is the logical
choice.

I understand that there are proposals for flexible submitInfo processing in
XForms, separating out the 'locator' portion from the 'body' section. We'll
see what the Working Group approves.

Thanks,

.micah

-----Original Message-----
From: Chris Lilley [mailto:chris@w3.org]
Sent: Sunday, February 24, 2002 2:45 PM
To: Micah Dubinko
Cc: 'www-tag@w3.org'; David E. Cleary (E-mail); 'paul@prescod.net'
Subject: Re: Background information on GET and XForms (was: GET should
be enco uraged...)


On Thursday, 24 January, 2002, 22:42:25, Micah wrote:

MD> The current (deprecated) state of GET in XForms started with a
MD> specific request (members only) [1] to remove the 'urlencoded'
MD> serialization format for internationalization reasons.

Yes. Its a huge wart, and source of great pain and lack of
interoperability, and makes writing form handlers much more
complicated than it needs to be.

MD> The XForms Working Group decided against removing GET, since the
MD> Requirements [2] mandate a solution that encourages migration from
MD> HTML forms, where GET is widespread, to XForms. The compromise
MD> position was to continue to support, but deprecate, 'urlencoded'
MD> (members only) [3]. Since 'urlencoded' was the only method defined
MD> to work with GET, GET was deprecated at the same time.

MD> If recent messages on this list are a guide, deprecating GET is an
MD> unpopular middle ground.

Yes, people seem worried about it. Personally I don't see the problem.
The basic processing model of XForms is to create and populate an XML
instance, which represents the result of filling in the form by
whatever means, and then to *send that XML instance to a server*.

There is a method in HTTP for making requests with message bodies. Its
PUT. GET is, in fact, PUT with a null message body .... a common
special case. But when there *is* a message body, which there is with
XForms, then sending it as an XML document seems sensible and forcing
it to be stuffed into a huge long url seems bizarre and awkward, even
if (as Micah suggests below) the encoding issues are resolved.

With the GET method, the form processor has to get hold of the url,
munge it, and extract the data. With PUT, the form processor gets an
XML instance and has to parse it, as XML - this is a rather well
understood technology.


MD> Suggested Resolution:

MD> XForms should adopt a slightly modified urlencoding process using
MD> [4] as a guide. Only UTF-8 encoding should be used for characters
MD> disallowed in URI references (instead of following the encoding of
MD> the containing document, as commonly implemented).

TRhat is certainly a valuable and useful suggestion, in the cases that
urlencoding and stuffing the entirte content into a URL is being done.
It fits with current work on IRI for example. 'Use the encoding of the
containing document' is a problem if there is no referer, or if the
containing document can have been served up in multiple possible
encodings, or if there *is* no containing document.

MD> The XForms document should clearly spell out that:

MD> * urlencoding is not encouraged for large amounts of data

Right. Although, someone can argue that a few megabytes is 'small'
because their idea of 'large' is terrabytes and up ...

MD> * urlencoding is not suitable for sensitive data that would appear
MD> in the URI and server logs

And proxy logs. This security aspect should certainly not be
underestimated.

MD> * this urlencoding approach is an improvement from current
MD> practice, and thus might not be compatible with some
MD> implementations that expect an OS-specific encoding

How many XForms implementations are there that expect a legacy
encoding? I agree its an improvement over current (HTML) practice. I
don't really agree that GET is superior to PUT - use the right tool
for the job. If there is no message body, just a retrieval request,
use GET. If there *is* a message body, in other words a transfer of
information from client to server, then POST is more appropriate.

MD> With this approach to urlencoding, no reason remains to deprecate
MD> GET. The wording to that effect should be removed.

MD> Comments?

I agree that GET should not be deprecated; it has uses. I don't agree
that GET is universally suitable for sending XML documents to servers
(rather the reverse) but then, I don't think you were arguing that it
was universally suitable either, just that it had some valid uses and
thus should not be deprecated.

MD> [1] http://lists.w3.org/Archives/Member/w3c-forms/2001JulSep/0752.html
MD> [2] http://www.w3.org/TR/xhtml-forms-req#from-html4
MD> [3] http://lists.w3.org/Archives/Member/w3c-forms/2001OctDec/0033.html
MD> [4] http://www.w3.org/International/2001/draft-masinter-url-i18n-08.txt


-- 
 Chris                            mailto:chris@w3.org

Received on Monday, 25 February 2002 16:38:14 UTC