Re: Method for A?

This is an interesting discussion, and parallels in some ways a discussion I
had with someone I know who was implementing an ISAPI filter.  He put links
in that changed the state, then returned a page based on the new state.
Obviously, any unexpected reloads caused problems.  In addition, clicking on
BACK, to look at the page printed as a result, caused the page to reload,
and caused unwanted state changes.  He was generating the pages dynamically,
so he added parameters on the links to let him decide if it was a reload.
This is obviously not a general solution.

The GET, as used above was causing unwanted side effects, was not "safe".
Doing a POST from the link would help, but would not go far enough.  It
could certainly stop gratuitus reloads.  But, the browsers are quite happy
to bookmark and remember in history a POSTed page.  If you go to the
bookmarked page, then the POST is resent, an explicit request from the user
to do something.  Unfortunately, it feels like you are bookmarking the
results, not the request.  If the POST says "go to some absolute state" (or
add some information to a DB for example), then the bookmark would seem fine
(the DB might not be as happy, I have dealt with this one, multiple
entries).  If the POST says "go to some relative state", then the results
will probably not be what the user wants.  History is even worse, since it
might have it, in which case the results are fine, or it might not have it,
in which case we are back to the bookmark situation.

I like the idea of indicating that a request may not be safe (POST).  In
addition for any POST, to allow server applications the best chance of
success, some way of having the UA indicate that this is a reload or an
original would allow the app to decide how best to deal with the request.
This could not be used by the UA as a license for reloading whenever it felt
like it, but would allow the server app to best present something reasonable
when a user "went back" to a POST.

Definitions would be needed for what "original" is, and some means of
passing the information (header ?).
Oh, but look, more extensions, this time to HTTP.

The method on A would be nice, allowing the UAs to better deal with dynamic
applications on the server, but does not do enough to help with state
management.

There is also the problem of something like the counter IMG.  If it needs to
be safe, there are a number of other questions.  First the IMG would need to
be extended.  There would also need to be a specification on how to deal
with POST objects in a page.  When can they be reloaded?  When must they be
reloaded?

>That depends on whether you consider incrementing the counter to be a
>"safe" action or not. If you don't consider an incorrect increment to
>be a bad thing, then you're fine. If you do consider such an increment
>to be bad, then fetching the object is unsafe, and hence you should be
>using the POST method to get it.

Which of course, you cannot do currently, and would require adding the
METHOD to IMG as well.


>Yup. However, if fetching the object isn't "safe", then the spec says
>you're supposed to use POST to get it. POST can only be used from
>FORM's. This means that all "unsafe" dynamic objects have to be
>fetched from a FORM, which is what I'm trying to fix.
>
>Of course, the reason for FIXING this is that browsers are fetching
>objects they think of as safe without checking with the user.

Yes, because the spec says that they can.  I agree, your extension would fix
this, but so would extending the display UI aspects of the form to allow
something A like.

>How is the giving the author more power to give the user more control
>of their browser a step backwards? Sure, REQUIRING that kind of
>behavior would be a major step backwards.  Allowing authors to say
>that fetching those objects may cause unsafe actions and so should be
>checked with the user is surely a step forward.

The problem here, is that in many cases the user is not the right person to
make that decision.  They do not know what is being done, and what is
safe/neccessary.  This is not intended as a comment on the abilties of the
users, but rather the lack of internal information.  In fact I would mostly
rather not know, that is why I think that helping the server app decide is a
useful addition to what you are proposing.


John Turner
johnt@cgocable.net

Received on Friday, 26 September 1997 16:28:47 UTC