[
Lists Home |
Date Index |
Thread Index
]
Hi Thomas,
Thomas said:
> You could argue that xslt should not be able to POST, because it is
> supposed to be free from "side effects", wheras a POST is supposed to add
> something to the addressed resource. True, such a change would not be to
> the original xml data being transformed, so the point could be argued
either
> way.
Didier replies:
Not necessarily, in fact if we go outside in the real world, the POST
function is used mainly to POST parameters to an application and this latter
returns a document, usually an HTML document as reply. This implies that the
HTTP POST processor does not necessarily modify anything. Moreover what is
defined in the RFC is that the POST method is used to send data/document to
the server, not that this latter has to modify anything. Thus, the HTTP POST
has no side effects on the server side too if the server has no intent to do
so. It is of common usage to use the POST function to POST forms to a server
and this latter to process it, and then return whatever document is the
associated to this processing.
Thomas said:
> In a practical sense, most processing libraries (cgi libraries, Cold
Fusion,
> etc.) handle a request the same way whether it has been receved by POST or
> GET so it is possible and, I think, common to simply use POST to transmit
> larger requests, or more secure ones, without intending to use the POST
> semantics of extending the resource. So if you could set the SOAP
headers,
> and subject to buffer size limitations, you could actually send SOAP
> messages using GET and I bet most systems would process them correctly (or
> could be made to do so with small modifications).
Didier replies:
If what is sent is a collection of parameters created from a form, then,
what is received by the processing agent (whatever the processing agent is:
ColdFusion, asp, jsp, etc) is the parameter's collection, not a request to
modify anything. Most of these processing environment present the HTTP
methods as verbs. Thus the script/program can make the distinction between
how to process the parameters. The data POSTED to the server could be
anything from a SQL request to an XML document used to encode a particular
domain language. The processing environments ressemble to object
implementations (in the case of jsp, this is the case) where verbs are seen
as methods and the scripts/procedures attached to these verbs could be
perceived as methods' implementations.
Does the default method associated to each verb could cause some side
effects? Just try to do a POST to a stored document (not a script) with
either Apache or IIS or check the result.
Several server systems impose a limit to URI strings. Also, the URI syntax
is more restrictive than is the POST body. This is why people tend to use
the POST to POST form's data.
Conclusion: The HTTP POST do not cause any side effect on the server side
nor does the RFC impose that the HTTP POST function is to be used _solely_
to modify server's content.
cheers
Didier PH Martin
|
