RE: GET should be encouraged, not deprecated,in XForms

On Wed, 23 Jan 2002, Ray Cromwell wrote:

> Shouldn't we shy away from letting users bookmark queries that are
> generated from forms anyway? It's inherently dangerous since not all
> GET requests are stateless and some rely on references to transient
> server data structures (e.g. the well known "session id")

Huh? The idempotence and independence requirements of HTTP GET versus POST
have been discussed to death during all these years. Of course you're
right when you say "not all GET requests are stateless", but just as well
"not all web pages are valid HTML". Any technology can be misused. This
shouldn't be a reason to deprecate methods that have clear and
well-defined meanings and a wide variety of correct uses.

While it's true that there are several web sites which count on cookies
and/or URI-based session identifiers, there are also huge amounts of
applications which do not require anything else but the user-input data
needed to fulfill the request. The GET method combines the possibilities
of accessing a resource both through a hyperlink and a form. Without
URI-based form submissions this functionality would be harder to
implement.

A phone directory could do quite well with, say, "GET
/address?bynum=123456789". A dictionary doesn't (necessarily) need
anything else but "GET /translation?word=car&fromlang=en&tolang=fi" and so
on. Why complicate use of simple resources by leaving a fundamentally
solid and sane method unsupported? 

The web community can definitely use more resources which can be accessed
through a simple URI instead of gigantic frameset-form-cookie-based web
applications. I believe that the easiest way to promote this sort of
functionality is to allow and encourage easy bookmarking directly after
form submission. If I search for a dictionary definition of a platypus and
want to send it to my friend as well, it is best for everyone if I just
can copy-paste the URL from the address bar into a mail message.

> Many sites, such as Dejanews/Google used to provide a
> link on the generated query results page that said
> "Click Here to Bookmark these results" and would
> include a specific A link that the user could
> right-click on and bookmark.

Yes, but I see this as a last-resort alternative. It is highly
recommendable for the original page to be bookmarkable itself; if some
sort of session/user tagging is absolutely required (and is not attainable
through use of other methods), then I find a separate bookmarkable page
acceptable.

> Moreover, Web developers need a way of indicating in a
> page whether the page's URI is bookmarkable or not,
> that way browsers could prevent users from trying to
> bookmark unbookmarkable pages.

True, although the issue is far more complicated than that. Say, we have a
site which uses a permanent cookie to store some truly necessary session
information. Now, a bookmarked page might work just fine, because the same
cookie exists and transports information in addition to the URL. But the
same bookmark would not work if you imported it into another browser, far
less if you just took the URL and stick it onto your web page.

So the question is not just whether or not the page can be bookmarked, but
rather "In what conditions will the created URI remain reusable (and
for how long)?". Developing a formal method to describe this aspect
environment-independently will be quite a challenge.

It is also important to realize that the concept of bookmarking is unclear
by itself. For most of the browsers, bookmark equals a stored URL. New
versions of IE are able to bookmark framesets correctly. That's a start,
but we're still far from perfect bookmarking: what SHOULD the bookmark
actually contain? In-page position and focus info? Form instance data
contents? State of the inline elements (Java applets, SVG
images)? JavaScript run-time variables?

This is getting seriously off-topic for the forms list, but the relevant
point is here: the issue of bookmarking with form submissions (and even
without them) is extremely demanding if it is to be addressed fully. The
division between GET and POST method semantics should be retained, since
it is the closest thing to a consensus the web world currently has on the
subject. I'll be happy to be corrected if someone knows better.

> In fact, people who use GET today with HTML forms are
> bound to run into trouble if they don't know what
> they're doing.

Granted, yet I could say the same about the whole web thing. The POST is
no saint either, it (or: the browser implementations) causes troubles too.
We could start with the breaking of back-forward chain with dialog boxes
stating "This page can only be viewed through re-submittal of form data
blah blah yadda yadda" and so on. Of course, if all the web sites used
GET and POST correctly, the dialog would almost never pop up in vain.


I understand the technical complications of encoding XML into a URI.
However, as it has already been pointed out in this list, a slightly
compromised solution should be possible. Forcing the flatness of
GET-submitted instance data is IMO acceptable despite the problems
involved.


Best regards,

Jouni

Received on Thursday, 24 January 2002 06:41:13 UTC