Lists Home |
Date Index |
--- Didier PH Martin <firstname.lastname@example.org> wrote:
> Off course, what is changing all this are the server side scripts and
> several issues like:
> a) the fact that an HTTP GET can include parameters in the URI. The document
> associated with the URI can be a script and thus create side effects.
> b) The fact that actual servers include the capability to overide any HTTP
Of course it can. The questions are whether it should and whether the user is
responsible if it does. The section above says it shouldn't, and the section
below says the user isn't responsible if it does.
> Jim said:
> > Naturally, it is not possible to ensure that the server does not generate
> > side-effects as a result of performing a GET request; in fact, some
> > resources consider that a feature. The important distinction here is that
> > user did not request the side-effects, so therefore cannot be held
> > for them."
> Didier replies:
> I agree that using SOAP to fetch a document is not the best method and all
> my posts reflect this point of view. We can say that independently of the
> HTTP method (either POST or GET), the simple fact that at the side a script
> process the method may lead to side effects. Simply because the method is
> used as an implicit function call. So, I guess that we should enforce the
> difference between document fetching and function call but that would
> contradict the actual practice of thousands if not millions of developers.
> We have more and more to face the web legacy and actual practices in our
My opinion: XSLT makes it easy to do the "right" thing (use GET to fetch an
HTTP resource) and harder to do the "wrong" one. (You can certainly write an
XSLT extension function to POST to a resource.) SOAP, on the other hand, makes
it impossible to do the "right" thing (use GET for safe, idempotent requests)
and easy to do the "wrong" one.
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more