[
Lists Home |
Date Index |
Thread Index
]
Hi Jim,
Jim said:
> POST brings more side effects because it is designed to have side effects,
> while GET is supposed to be safe. Quoting from section 9.1.1 of RFC 2616
[1]:
>
> "In particular, the convention has been established that the GET and HEAD
> methods SHOULD NOT have the significance of taking an action other than
> retrieval. These methods ought to be considered "safe". This allows user
agents
> to represent other methods, such as POST, PUT and DELETE, in a special
way, so
> that the user is made aware of the fact that a possibly unsafe action is
being
> requested.
Didier replies:
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
method
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
dynamic
> resources consider that a feature. The important distinction here is that
the
> user did not request the side-effects, so therefore cannot be held
accountable
> for them."
>
> Note that we are talking about side effects on the server, not any effect
the
> document() function would have on the output of the XSLT tranformation.
>
> > Off course, when used in the context of the "document" function (or
> > anything else having the same intent: fetching an XML document). The
basic
> > goal of any construct like the "document" function is to fetch an XML
> > document.
Didier replies:
yes
Jim said:
>
> But POST is not intended for fetching documents. That is what GET is for.
From
> section 9.5 of the RFC [2]:
>
> "POST is designed to allow a uniform method to cover the following
functions:
>
> - Annotation of existing resources;
>
> - Posting a message to a bulletin board, newsgroup, mailing list,
> or similar group of articles;
>
> - Providing a block of data, such as the result of submitting a
> form, to a data-handling process;
>
> - Extending a database through an append operation."
>
> Of course this is one of the REST proponents' objections to SOAP--if you
want
> to fetch a document using the SOAP HTTP binding you must use an HTTP POST,
> which violates the semantics specified in the HTTP spec.
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
thinking.
cheers
Didier PH Martin
|
