- From: Chris Lilley <chris@w3.org>
- Date: Sun, 24 Feb 2002 23:44:40 +0100
- To: Micah Dubinko <MDubinko@cardiff.com>
- CC: "'www-tag@w3.org'" <www-tag@w3.org>, "David E. Cleary (E-mail)" <davec@progress.com>, "'paul@prescod.net'" <paul@prescod.net>
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 Sunday, 24 February 2002 18:42:12 UTC