Subject: [Simple] PUT vs POST in XCAP

From: Dean Willis <[email-masked]>
Date: Wed, 03 Mar 2004 21:56:42 -0600

This became a heated discussion in today's XCON meeting.

I believe that the heart of the discussion around PUT vs POST hinges on 
the following:

Is the operation:

1) Storage of a resource into a repository

or

2) Invocation of server-side logic on a parameter set being passed to 
that logic.

Given that at least some of the CPCP logic has the server making a 
transformation to the parameter set (adding the conference URI element), 
I believe that we fall into case 2. Certainly it would be much easier to 
build an XCAP implementation on Apache's HTTPD using a POST interface 
than it would using a PUT interface.

For reference, it should be noted that both XML-RPC and SOAP use POST to 
invoke server-side logic.

For example, see:

http://www.w3.org/TR/soap12-part0/#L26866

which says:

4.1.2 SOAP HTTP POST Usage
Using the HTTP binding with the SOAP Request-Response message exchange 
pattern is restricted to the HTTP POST method. Note that the use of this 
message exchange pattern in the SOAP HTTP binding is available to all 
applications, whether they involve the exchange of general XML data or 
RPCs (as in the following examples) encapsulated in SOAP messages.

Examples 9 and 10 show an example of a HTTP binding using the SOAP 
Request-Response message exchange pattern, using the same scenario as 
that for Example 4 and Example 5a, respectively, namely conveying an RPC 
and its return in the body of a SOAP message. The examples and 
discussion in this section only concentrate on the HTTP headers and 
their role.

Example 9
POST /Reservations HTTP/1.1
Host: travelcompany.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
  <env:Header>
    <t:transaction
            xmlns:t="http://thirdparty.example.org/transaction"
            env:encodingStyle="http://example.com/encoding"
            env:mustUnderstand="true" >5</t:transaction>
  </env:Header>
  <env:Body>
   <m:chargeReservation
      env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
           xmlns:m="http://travelcompany.example.org/">
    <m:reservation xmlns:m="http://travelcompany.example.org/reservation">
     <m:code>FT35ZBQ</m:code>
    </m:reservation>
     <o:creditCard xmlns:o="http://mycompany.example.com/financial">
      <n:name xmlns:n="http://mycompany.example.com/employees">
            Åke Jógvan Øyvind
      </n:name>
      <o:number>123456789099999</o:number>
      <o:expiration>2005-02</o:expiration>
     </o:creditCard>
    </m:chargeReservation>
   </env:Body>
</env:Envelope>RPC in Example 4 carried in an HTTP POST Request

This usage smells a whole lot like XCAP's to me.

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: [email-masked]
Date: Tue, 9 Mar 2004 09:50:39 +0000

>That said, assuming Dean's assessment of apache operation is correct
>(can someone verify that PUT works this way? I always thought one could
>write a servlet that handles PUT...), this would pose a problem. A key
>goal of XCAP is that it was easily built on existing servers and
>existing wireless clients. If people know of reasons why this goal has
>not been met, we should explore that.

Hi,

Another technology that has a problem with PUT is J2ME.  It's been my
experience that a large percentage of J2ME implementations used in mobile
phones only support GET / POST / HEAD.  The API for the HttpConnection
class in MIDP 1.0 / 2.0 doesn't even specify a field for other methods then
those 3 ones and the spec only mandates support for HEAD, GET and POST
requests leaving the rest optional.

wr,
Jon Ingi
OZ Communications

---

From: [email-masked]
Date: Tue, 9 Mar 2004 09:50:39 +0000

Hi,

wr,
Jon Ingi
OZ Communications