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

> > -----Original Message-----
> > From: Micah Dubinko
> > Sent: Thursday, January 24, 2002 1:42 PM
> > To: 'www-tag@w3.org'
> > Cc: David E. Cleary (E-mail); 'paul@prescod.net'; 'chris@w3.org'
> > Subject: Background information on GET and XForms (was: GET should be
> > encouraged...)
> >
> >
> > Here is some helpful background information and a suggested
> > resolution. This
> > message is to help the TAG make an informed decision, and is not on behalf
> > of the XForms Working Group.
> >
> > The current (deprecated) state of GET in XForms started with a specific
> > request (members only) [1] to remove the 'urlencoded' serialization format
> > for internationalization reasons.

Yes, it is very important that XForms provides a clean solution here.


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

In terms of web architecture, at least as far as I understand it,
GET is for requests that don't change server state,
POST is for requests that change server state (sending data),
and PUT is for requests that add or replace a resource.

The fact that 'urlencoded' is the only thing that currently works
well with GET is largely a result of early incomplete implementations
and deployment dependencies.

As far as I understand, there is nothing against GET with body,
and it should be seriously considered for XForms.


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

As far as I understand, it was a goal of XForms to be able to work
with deployed server-side scripts,... if desired. In that case,
changing this convention would be a really bad idea. If there is
no need for backwards compatibility, then indeed fixing things
to UTF-8 is exactly the right thing thing to do.


> > The XForms document should clearly spell out that:
> >
> > * urlencoding is not encouraged for large amounts of data

Right.


> > * urlencoding is not suitable for sensitive data that would appear in the
> > URI and server logs
> > * this urlencoding approach is an improvement from current practice, and
> > thus might not be compatible with some implementations that expect an
> > OS-specific encoding

The current encoding is not OS-specific. The encoding of the page
that contains the form is used. This may in some cases coincide with
the encoding of the OS that the page is served from, but that's not
at all necessary.


Regards,    Martin.

Received on Sunday, 27 January 2002 12:40:59 UTC