Subject: RE: [Simple] XCAP: what does in the 200 of a PUT request

From: [email-masked]
Date: Fri, 12 Dec 2003 09:07:58 +0200

The real question is: is it wrong to have a body in a HTTP 200 response for a PUT request? If not, can XCAP define what goes in the body?

If a body in the 200 is wrong, does that mean the XCAP client needs to follow the PUT with a GET to learn of the XCAP usage resource interdependencies?

Regards,
Hisham

> -----Original Message-----
> From: ext Ted Hardie [mailto:[email-masked]]
> Sent: 11.December.2003 20:50
> To: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked]
> Subject: Re: [Simple] XCAP: what does in the 200 of a PUT request
> 
> 
> At 11:42 AM +0200 12/11/2003, [email-masked] wrote:
> >This is not clear in XCAP. I also check RFC2616 to find out 
> some sort of answer, but it is not clear there either.
> 
> The 200 response doesn't require a response body for HTTP.  
> You can define
> a response body appropriate for a specific method  (Julian Reschke has
> a webdav-related example in his draft for checkin; a uri for that is:
> http://www.greenbytes.de/tech/webdav/draft-reschke-deltav-comp
> ute-checkin-uri-01.html)
> For PUT, though, you should probably be able to handle 
> getting a bare 200 response (see
> section 9.6 of RFC 2616.)
> 
> Or am I misunderstanding your question?
> 				regards,	
> 					Ted Hardie
> 
> 
> >Should the 200 (or 201 for that matter) contain the contents 
> the were PUT? If so, does it include the resource 
> interdependencies (like the resource list URI in the list case)?
> >
> >If no, does that mean the client needs to follow the PUT 
> with a GET to learn of the resource interdependencies?
> >
> >Thanks,
> >Hisham
> >
> >_______________________________________________
> >Simple mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/simple
> 
> 

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

---

From: Ted Hardie <[email-masked]>
Date: Fri, 12 Dec 2003 15:18:22 -0800

>The real question is: is it wrong to have a body in a HTTP 200 response for a PUT request? If not, can XCAP define what goes in the body?

I think the answers are no, no, yes, and no.  But that's partly because I think you are
missing a few questions.  A 200 response can have a body.  (Unstated question:  is
this expected behavior now?)  No, not really.  Mostly a PUT results in a 200 OK and
the client is satisfied that the PUT succeeded.  Can XCAP define what goes in the
body:  Yes, but as I said below, clients will probably need to be to handle the case
where they get a "bare" 200.  If they are counting on data in the response
body there are cases where they will likely break.  (Unstated question: is a response
body the right tool here?).  No, not in my opinion (NB: no AD hat, just an opinion). 
One of the key reasons for using PUT and making some of the early changes to
XCAP was to keep the functionality as a strict subset of the HTTP functionality. 
That was a good idea from a spec, code, and deployment perspective.  If you return response
bodies to a PUT along with the 200 response, you're edging out of that "strict subset"
mentality, and the more protocol logic is in the response body the further out you
are.  It's not impossible, but other design choices may make more sense.
				regards,
					Ted

---

From: Ted Hardie <[email-masked]>
Date: Fri, 12 Dec 2003 15:18:22 -0800

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 15 Dec 2003 10:32:13 -0500

Ted Hardie <[email-masked]> writes:

> One of the key reasons for using PUT and making some of the early
> changes to XCAP was to keep the functionality as a strict subset of
> the HTTP functionality.  That was a good idea from a spec, code, and
> deployment perspective.  If you return response bodies to a PUT
> along with the 200 response, you're edging out of that "strict
> subset" mentality, and the more protocol logic is in the response
> body the further out you.

I don't understand why POST wasn't chosen then; it does not have that
problem in that most things expect a body in response to a post.

I also think that POST is a better choice because the usual intent (as
I understand it) in xcap will be to provide data to be used to modify
the object at the URI rather than the entire resource.  POST seems to
me to be a better match for that given the definitions of the methods
in HTTP (taken from draft-gettys-http-v11-spec-rev-00.txt - recently
published draft candidate for full Standard status):

  9.5 POST 

     The POST method is used to request that the origin server accept the 
     entity enclosed in the request  as data to be processed by the 
     resource identified by the Request-URI in the Request-Line.

  9.6 PUT 

     The PUT method requests that the enclosed entity be stored under the 
     supplied Request-URI. If the Request-URI refers to an already 
     existing resource, the enclosed entity SHOULD be considered as a 
     modified version of the one residing on the origin server. 

-- 
Scott Lawrence        
  Pingtel Corp.

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 15 Dec 2003 10:32:13 -0500

9.5 POST 

  9.6 PUT 

-- 
Scott Lawrence        
  Pingtel Corp.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 15 Dec 2003 16:11:10 -0500

inline.

> problem in that most things expect a body in response to a post.

Sure; but this is not a case where the resouce represented by the 
r-uri is meant to process the content. Rather, the content really is 
meant to be placed on the server at the designated URI. The fact that, 
in many cases, the placement occurs in the middle of an XML document, 
seems irrelevant to me.

> the object at the URI rather than the entire resource. 

See above; it depends on your interpretation of resource. In our 
interpretation, the URI points to snipits of XML documents that, when 
put together, form the whole document.

The original version of this spec had POST *and* PUT; one was used for 
insert, the other for modify. There was strong pushback that using 
POST was a sure sign that this was an abuse of http, since you could 
really build any protocol through POST.

> are.  It's not impossible, but other design choices may make more sense.

This was my thought as well. I did not think that the PUT returned the 
current content in the body. So, if you create a list, and the server 
needs to provide the list URI, you will need to PUT then GET the list 
to learn the URI.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 15 Dec 2003 16:11:10 -0500

inline.

-Jonathan R.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 15 Dec 2003 13:34:01 -0800

Hi Scott,

>published draft candidate for full Standard status):

The difficulty here was the usual difficulty with POST--the semantics
of the operation that occurs once the server has accepted the entity
are outside the bounds of HTTP.  You can layer another protocol on
top of POST and return its protocol semantics in the body, but doing
so means you can't really take advantage of existing clients.  The clients
have to *at least* understand how to parse the returned bodies
to extract failure conditions and react accordingly.  By using a
structured view of the resources, on the other hand, you can use
PUT in a way that consonant with the base HTTP semantics.  A secondary
advantage is that building it on top of PUT means you may be able
to move toward DAV over time without having to later reconcile the
POST-based protocol semantics with the DAV HTTP-based protocol
semantics.

		regards,
			Ted HArdie

---

From: Ted Hardie <[email-masked]>
Date: Mon, 15 Dec 2003 13:34:01 -0800

Hi Scott,

		regards,
			Ted HArdie