[Didier PH Martin]
>  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.
> 

I think there's a difference between what the HTTP RFC says about POST (with
SHOULDs, not MUSTs) and what is done using HTML .  It's HTML forms (with
form encoding) that carry name/value pairs, and GET query fragments are by
convention also treated as name/value pairs.  In actual practice, as I think
we have both said, there is almost no practical difference between sending a
POST or a GET to a web server.  At least not until SOAP, which has some
headers to tell the server to do something different.

>  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.
> 

Sure (and I think we agree), it's always up to the server how it will
respond.  Still, if one really followed the prescriptions in the HTTP RFC,
one would use GET and POST for different kinds of things.

>  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.
> 

Right, that's more or less what I was saying.

>  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.
> 

The RFC doesn't  impose that because it doesn't use "MUST", only "SHOULD".
I have been assunimg that much of this thread has been concerned with
pretending that the word had been "MUST", in the interest of trying to keep
a clean architecture and staying within the clearly expressed intent of the
RFC ("SHOULD"= "clearly expressed intent").

Cheers,

Tom P


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>