W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2006

Re: Extension methods & XMLHttpRequest

From: David Morris <dwm@xpasc.com>
Date: Wed, 14 Jun 2006 09:35:54 -0700 (PDT)
To: Julian Reschke <julian.reschke@gmx.de>
cc: <ietf-http-wg@w3.org>
Message-ID: <Pine.LNX.4.33.0606140923470.26008-100000@egate.xpasc.com>



On Wed, 14 Jun 2006, Julian Reschke wrote:

>
> David Morris schrieb:
>
> > On Mon, 12 Jun 2006, Julian Reschke wrote:
> >
> >> David Morris schrieb:
> >>> ...
> >>> This is a specific case where the protocol design has ignored the
> >>> realities of application user interaction design. I have found
> >>> no alternatives to form.submit() within onload to achieving rich
> >>> and smooth applications.
> >>> ...
> >> Now that's an interesting statement. It would be nice if you could
> >> expand on this, because it would be useful to understand what kind of
> >> use cases are solved using this method.
> >
> > Application Example: You have two frames where one depends on the other in
> >   some fashion. If the onload for FrameA initiates the load of FrameB,
> >   FrameB logic can be sure that FrameA data objects are present.
> > Application Example 2: The application has a main window and a data
> >   entry dialog. When the user input from the dialog is commited, the
> >   main window requires a reload. The onload for the dialog window
> >   initiates the refresh of the main window by calling a javascript
> >   method in that windows and then closes the dialog window.
> >
> > Misc. Example: Timing web page loads in the style of www.numion.com's
> > stopwatch facility requires careful coordination of loading two visible
> > frames after the base frameset is loaded. Use of onload to trigger the
> > next step provides that synchronization.
> >
> > Dave Morris
>
> David, maybe I'm a bit slow, maybe there's a misunderstanding...
>
> What I was saying is that calling an *unsafe* method such as POST upon
> "onload" is problematic. I didn't argue against "onload" in general. So
> do these use case require an unsafe action being performed
> automatically, or wouldn't GET be sufficient here?

Well, the notion of unsafe is really an application notion. Browsers
protect applications by attempting to warn the user before repeating a
POST which might repeat a data base change. The application designer needs
to make the decision as to whether POST or GET is appropriate. Because of
the wide variety of GET / no-cache / etc. implementations, I have much
more faith that a POST response will not be re-used than I do for a GET
response. So based on application requirements, the decision to use POST
or GET should be the application designers. There are also payload issues
between GET and POST.

I see no reason to distinguish between POST and GET in the case of onload
or other scripted execution of HTTP requests. My applications make heavy
use of the ability to process an ONCLICK event on an anchor to submit the
form. Perhaps because I want a pretty button or because a set of buttons
just makes a crummy layout. For example, we had several possible actions
on an object. As links, the actions laid out well, took minimal space,
etc. Use of buttons would have been horrible.

I have noted a rather significant move to this style of command object
on desk top guis as well.

POST is unsafe to repeat without user interaction (unless the experimental
SAFE rfc provisions are implemented). There should be no additional
implications related to POST.

Dave Morris
Received on Wednesday, 14 June 2006 16:36:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:44 GMT