succeed code for DELETE

Hi,
Can a successful DELETE (in my case, deletion of a version-history) return some content (some href, for
example) to the client? 
RFC 2158 states that 204 (no content) is the default success code for DELETE.  I was wondering if there are
special deltaV semantics.

Thanks,
Girish

Re: succeed code for DELETE

RE: succeed code for DELETE

Hi Geoff,
Yes, I meant 2518..that was a typo.

At the end of section 8.6 (DELETE), there is a statement which states that 204 should not be included in a 207. 
"The reason for this prohibition is that 204 (No Content) is the default success code."
It was this particular phrase which confused me.

Regards,
Girish

________________________________

	From: ietf-dav-versioning-request <at> w3.org [mailto:ietf-dav-versioning-request <at> w3.org] On
Behalf Of Geoffrey M Clemm
	Sent: Tuesday, September 14, 2004 7:09 PM
	To: 'ietf-dav-versioning <at> w3.org'
	Subject: Re: succeed code for DELETE
	
	

	I assume you meant "2518", not "2158". 
	
	What in 2518 made you think 204 was the "default" success code 
	for DELETE?  In particular, the definition of DELETE in 2518 
	(which is a copy of the definition from 2616) states: 
	
	"A successful response SHOULD be 200 (OK) if the response includes 
	an entity describing the status, 202 (Accepted) 
	if the action has not yet been enacted, or 204 (No Content) 
	if the action has been enacted but the response does not 
	include an entity." 
	
	So you would use 200 or 202 if you wanted to include a body. 
	
	Cheers, 
	Geoff 
	
	
	Girish wrote on 09/14/2004 10:42:32 AM:
	
	> 
	> Hi,
	> Can a successful DELETE (in my case, deletion of a version-history) 
	> return some content (some href, for example) to the client? 
	> RFC 2158 states that 204 (no content) is the default success code 
	> for DELETE.  I was wondering if there are special deltaV semantics.
	> 
	> Thanks,
	> Girish
	> 
	

DAV:checked-out property of a working-resource

Hi,
What should be the DAV:checked-out property of a working resource, when the working resource was created
due to a CHECKOUT on a version-controlled-resource with DAV:apply-to-version?  Should it be equal to the
DAV:checked-in property of the version-controlled-resource at the time the CHECKOUT was done?

Thanks,
Girish

PS: I must admit that after nearly 2 years of association with DeltaV and umpteen number of readings of the
spec, every new reading brings in some confusion somewhere! :( Maybe things would have been simpler if the
versioning semantics were clearly separated out from the protocol behavior.

Re: DAV:checked-out property of a working-resource

RE: succeed code for DELETE

Re: succeed code for DELETE

Geoffrey M Clemm wrote:
> 
> Good catch, Girish!
> 
> RFC-2518bis team: Please add this to the list of editorial issues
> for 2518.
> 
> These two sentences in 8.6 (in 8.7 of 2518bis) should be deleted.
> The first sentence is wrong, because 204 is not an error, and so
> there is no such thing as a "204 (No Content) error".
> The second sentence is wrong, because 204 (No Content) is not
> the "default success code".
> 
> Cheers,
> Geoff

+1

> Girish wrote on 09/15/2004 02:58:50 AM:
>  > At the end of section 8.6 (DELETE), there is a statement which
>  > states that 204 should not be included in a 207.
>  > "Additionally 204 (No Content) errors SHOULD NOT be returned in
>  > the 207 (Multi-Status).The reason for this prohibition is that
>  > 204 (No Content) is the default success code."
>  > It was this particular phrase which confused me.
> 
>  >    Girish wrote on 09/14/2004 10:42:32 AM:
>  >    > Can a successful DELETE (in my case, deletion of a version-history)
>  >    > return some content (some href, for example) to the client?
>  >    > RFC 2158 states that 204 (no content) is the default success code
>  >    > for DELETE.  I was wondering if there are special deltaV semantics.

Yet, why would you *want* to send a response body upon DELETE?

Best regards, Julian

--

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

RE: DAV:checked-out property of a working-resource

The ambiguity comes in if the two post-conditions are read in isolation.  The fact that they define
different semantics for the DAV:auto-update property led me to believe that they may also define
different semantics for the other properties like DAV:checked-out.

So, in reality:

DAV:create-working-resource-from-checked-in-version (VCR URL, DAV:apply-to-version)
	working-resource <-- DAV:create-working-resource(VCR::DAV:checked-in)
	working-resource::DAV:auto-update <-- VCR URL

Probably some redundancy would have made it clearer.

Regards,
Girish

________________________________

From: ietf-dav-versioning-request <at> w3.org [mailto:ietf-dav-versioning-request <at> w3.org] On Behalf
Of Geoffrey M Clemm
Sent: Wednesday, September 15, 2004 1:51 PM
To: 'ietf-dav-versioning <at> w3.org'
Subject: Re: DAV:checked-out property of a working-resource

	Girish wrote on 09/15/2004 05:34:16 AM:
	> What should be the DAV:checked-out property of a working resource, 
	> when the working resource was created due to a CHECKOUT on a 
	> version-controlled-resource with DAV:apply-to-version?  Should it be
	> equal to the DAV:checked-in property of the version-controlled-
	> resource at the time the CHECKOUT was done?
	
	The semantics of CHECKOUT to create a working resource is defined 
	in section 9.3 "CHECKOUT Method (applied to a version)". 
	
	Postcondition DAV:create-working-resource-from-checked-in-version states: 
	      If the 
	      request-URL identified a version-controlled resource, and 
	      DAV:apply-to-version is specified in the request body, the 
	      CHECKOUT is applied to the DAV:checked-in version of the version- 
	      controlled resource, and not the version-controlled resource 
	      itself. 
	
	Postcondition DAV:create-working-resource states: 
	      The DAV:checked-out property of the new 
	      working resource MUST identify the version that was checked out. 
	
	So since the CHECKOUT is applied to the DAV:checked-in version and the 
	DAV:checked-out property identifies the version that was checked out, 
	then yes, the DAV:checked-out property of the new working resource 
	identifies the DAV:checked-in version. 
	
	Is there something in the spec that led you to believe otherwise? 
	
	Cheers, 
	Geoff 
	
	

RE: DAV:checked-out property of a working-resource

proxy and webdav

Hello,

I am currently studying subversion.
We have multiple sites and low network bandwidth, so we would like to 
set up a proxy, with a cache.
You mention in your website that there is some problems with some proxies.

So i have set up a proxy with apache 1.3, and a config file for a cache. 
It caches request properly, but subversion requests are not cached.

My questions are:

Is proxy caching taken into account in webdav and deltaV specifications ?
Is there a better proxy that implement correct webdav and deltaV caching ?
If it could work, do you have a configuration example for apache ?

Thanks for your help

  Ronan Meneu