Subject: New "200 OK" status codes, PATCH & PROPFIND

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 06 Aug 2007 18:30:28 +0200

Regarding the new proposed "209 Content Returned" status code.

I think recent discussions show that there is actually a need for two
new status codes.

209 Content Retuned
to be used when the entity has been modified. If the resource varies
then the response MUST contain a Vary header telling which request
headers the variance is based on just as for a GET. If any of those
headers is not present in the request due to special method requirements
then "Vary: *" must be used. A cache may update it's cache with the
returned entity, and any old matching responses MUST be invalidated.
This response status is identical to 200 OK in all regards except that
it's defined to always return the current requested entity and MUST NOT
be used for returning method specific status responses.

210 Information returned
to be used when auxillary information about the requested entity or
resource is returned. This response do not invalidate any cached
entities for the URI. The response may contain a Content-Location
indicating an URI where the same information can be retreived using GET
and optionally an Content-ETag header providing the current ETag for the
same.

Example use case for "209 Content Returned" is PATCH.

Example use case for "210 Information Returned" is PROPFIND

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Aug 2007 19:54:14 +0200

Henrik Nordstrom wrote:
> ...
> ...

The problem with 210 (instead of 207) is that you can't deploy it. 
Clients expect 207. So either we'd need to expand the semantics to 207, 
or clients would need to be able to signal they understand 210.

It seems that you're trying to mirror the GET-Location header 
functionality into status codes and existing headers, with which I 
sympathize.

But wouldn't we also need some mechanism for the validity time, see 
"max-age" in 
<http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html#rfc.section.3>?

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 6 Aug 2007 13:11:41 -0700

> I think recent discussions show that there is actually a need for two

okay, but only if it is forbidden as a response to GET.  There is no
need to make any special reference to Vary or Cache-control -- just
define all fields to be interpreted as if the request method had been  
GET.

> 210 Information returned

No way.  That is what Content-Location provides.  We don't need a
Content-Etag header field -- the Etag response header field would
always have the same value.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Aug 2007 22:21:39 +0200

> always have the same value.

I have to disagree here. This is not what RFC2616 says, which defines 
the Etag in terms of the "requested variant". Let's clarify this one first!

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 6 Aug 2007 13:54:02 -0700

On Aug 6, 2007, at 1:21 PM, Julian Reschke wrote:
> I have to disagree here. This is not what RFC2616 says, which  
> defines the Etag in terms of the "requested variant". Let's clarify  
> this one first!

I already defined it, and yes it says the same thing.  The requested
variant is the same whether the method is GET propURI or PROPFIND  
resURI.
If an etag exists for the properties, it is going to have the same value
whether those properties are retrieved via GET propURI or PROPFIND  
resURI.

What might differ is the etag of the entity that would have been
retrieved via a GET resURI, where resURI != propURI, since the
GET resURI etag is actually a value within the properties of resURI
and only needs to change when the content of the resURI entity changes,
not when the content of its properties change.

Did I mention that PROPFIND is evil?  Properties of a resource are a
different set of resources.  PROPFIND is merely a GET with one level
of indirection built-in, and everything in the response has to be
interpreted that way or we'll all go nuts.  RFC 2616 does not
standardize because I was hoping that PROPFIND wouldn't exist.

....Roy

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 06 Aug 2007 23:32:02 +0200

On mån, 2007-08-06 at 13:11 -0700, Roy T. Fielding wrote:

> > 209 Content Retuned
> 
> okay, but only if it is forbidden as a response to GET.

Agreed. It's only a patch to work around the earlier specification
mistakes allowing 200 OK to be used for "aux information" different from
the requested entity.

But the more I think about this the less convinced I get that a new "200
OK here is your content" status code is needed. Simply providing a
Content-Location or expiry information in the 200 OK should be
sufficient. I.e. a generalisation of the POST rules, adding
Content-Location as an alternative criteria an applying it to any method
unless the method definition says otherwise.

> There is no

Fine by me.

> always have the same value.

Thats what my gut says as well, but this talk about "requested variant"
got me a bit worried. Currently the concept of "GET like non-GET
methods" fits rather poorly in the cache model of RFC2616.

Well, back on that topic. Here is a definition of "requested variant"
which would work out quite reasonably I think:

requested variant
	the entity returned if the same request had been a GET request
	sent to the Content-Location URI, or Request-URI if no
	Content-Location header is present in the response.

About the only special case where the Request-URI could be used equally
to Content-Location in this is HEAD, but then HEAD is a bit of a special
case in itself..

For many other methods the meaning of Content-Location is very
significant as a simple transition of the request to GET doesn't account
for all the possible variance vectors involved. I.e. a PUT to a Vary:ing
URI might only update one variant of that resource, possibly different
from what the same request as a GET would return. Even more so for
PATCH. And PROPFIND returns information from a different namespace.

Then the cache invalidation rules needs to be refined a bit to avoid
things like PROPFIND flushing all cached variants of the requested URI.
It's not realistic that caches should need to learn every new "GET-like"
method people invent..

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Tue, 07 Aug 2007 09:36:37 +1200

I'm probably going to get shot down for this but... just an observation

All these extensions to the core protocol to deal with relatively 
minority cases seems problematic to me.

Modifications to the protocol require adoption by all parties in any 
comms.  There's a lot of infrastructure out there that won't change: 
proxies, servers... clients.

Add to that the proposed complexity of "Preferences" vs "Expectations".  
The problem with preferences is they are non-deterministic.  Just like 
in real life (i.e. with people) :)

So, my suggestion would be to layer something over the top of HTTP for 
use-cases like this.  Use SOAP or something, and define the XML that 
goes back and forth to do this editing and patching as a separate spec, 
but leave HTTP alone.  Then modifications to the requirements for the 
special situations are independent of the transport protocol.

imagine if we extended TCP whenever we wanted some new application-level 
functionality?

Regards

Adrien

Julian Reschke wrote:
> Clients expect 207. So either we'd need to expand the semantics to 
> 207, or clients would need to be able to signal they understand 210.
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 06 Aug 2007 23:36:38 +0200

> <http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html#rfc.section.3>?

"Cache-Control: max-age=nn" is the obvious choice. Already mentioned
earlier in the get-location thread.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 06 Aug 2007 23:40:56 +0200

> 	Content-Location header is present in the response.

Not entirely complete.. needs to add "after this request has been
processed" in all cases except DELETE. This to account for
POST/PATCH/PUT etc modifying the requested entity.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Aug 2007 23:43:00 +0200

> earlier in the get-location thread.

Henrik,

Cache-Control applies to the response. What the proposal is about is to 
enable the server to say that

(a) the response body (DAV:multistatus) is cachable for n seconds, while

(b) the substitute URL can be used for N seconds,

where N >> n.

So these are really different things.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Aug 2007 23:49:32 +0200

Roy T. Fielding wrote:
> variant is the same whether the method is GET propURI or PROPFIND resURI.

Well, that definition is not in RFC2616. Can we please agree on a 
proposed change, and add that to the resolution for 
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i69>?

> whether those properties are retrieved via GET propURI or PROPFIND resURI.

In which case the ETag will depend on both some request headers (such as 
"Depth"), *and* the request body. This may be a problem for some proxies.

> not when the content of its properties change.

Right.

> Did I mention that PROPFIND is evil?  Properties of a resource are a

I think so :-). GET-Location just is trying to make it less evil.

> standardize because I was hoping that PROPFIND wouldn't exist.

GET-Location exposes that indirection, so clients can actually do 
something better once they know it.

It seems that we all agree that it's good to give the client a URI of 
something GET can be applied to. Let's just find the best way to do that.

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 6 Aug 2007 15:52:30 -0700

> unless the method definition says otherwise.

Yes, it should be sufficient, which is what Mark was saying
in the first place.  But it was (intentionally) defined that way
over 10 years ago and nobody uses it, even though there are plenty
of use cases for which it applies. Maybe just adding a lot more
text to how Content-Location should be interpreted for all methods,
and how Cache-control/Expires/ETag apply along with it, will be
enough to make people use it as specified.  *shrug*

> methods" fits rather poorly in the cache model of RFC2616.

That's because they should have been forbidden.  The entire point of
the Web is to increase the number of identifiable resources (hence,
linkable information).

> 	Content-Location header is present in the response.

No.  The variant is not an entity.  Think of variant as the target
of a request once URI+Vary-fields is taken into account.  It is the
resource-as-subdivided-by-negotiation, which was the original definition
before it got mixed up in committee.  Now, if we add the notion of
a method that acts by indirection (PROPFIND), then we merely add
that notion to the definition in general.

    variant
       The ultimate target resource of a request after indirections
       caused by content negotiation (varying by request fields) and
       method association (e.g., PROPFIND) have been taken into account.
       Some variant resources may also be identified directly by their
       own URI, which may be indicated by a Content-Location in the
       response.

> PATCH. And PROPFIND returns information from a different namespace.

I don't see why this keeps coming up.  PUT does not vary.  If you PUT
to a negotiated resource, the resource must do one of:

    1) change the state of all the variants in accordance with that
       PUT (which may involve quite a bit of background magic,
       depending on how those other variants are defined/generated
       from a common resource model);

    2) redirect the PUT to a non-negotiated URI; or,

    3) return 405 (method not allowed) or some other error code.

In particular, HTTP does not allow the fourth option of

    4) change only the variant that shares the same Content-Type or
       Content-Language, or which might be indirectly identified by
       looking at the Accept* headers.

HTTP requires that PUT only be used to directly modify a resource,
since any other interpretation would not allow for option (1) and
thus would not match the method semantics.

The same should apply to PATCH.  The Accept headers define what is
acceptable in the response entity, which is not recommended for a
state-changing operation.  The Content-* headers define the entity
that is included in the request payload (the patch data).  Even
when the patch data contains metadata that indicates which variant
is being patched, the result of the state change must be reflected
in all variants.  Otherwise, PATCH does not have uniform semantics.

That is why most negotiated URIs should respond to state-changing
operations with a redirect to the specific authorable resource(s)
of which the negotiable resource is composed.  Negotiable URIs
are just another form of dynamic content generation, and should
be handled in the same manner unless that generation is very
simple, such as a resource that negotiates deflate content encoding
in which the result of authoring one (un)compressed variant is
easily applied to the other (un)compressed variant.

....Roy

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 07 Aug 2007 00:56:00 +0200

> (b) the substitute URL can be used for N seconds,

Is there really a need to time-limit the substitute URL?

Imho this should be to an permanent alternative URL-namespace for
accessing the properties, existing even before the request has been
seen. If the URI disappeares for whatever reason the client will need to
fall back on PROPFIND, or whatever method is used in future to find the
"PROPFIND URI namespace schema".

There is no problem for PROPFIND to define that this Content-Location is
permanent.

There is also no problem for PROPFIND to define that result may be
cached on that URI without first issuing a GET under restricted
conditions (i.e. at least same host as in the Request-URI) even if I
would advice some caution there to avoid cache pollution security
issues, and would therefore recommend to only allow the end-client to
cache the entity for the purpose of PROPFIND alone, not "non-PROPFIND"
GET's for the same URI (note: the restriction on host is then not
needed).

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 07 Aug 2007 01:07:38 +0200

> enough to make people use it as specified.  *shrug*

It's probably at least as effective as adding a new status code, and
with the positive sideeffect that implemented actually finally
understand Content-Location.

Yes, there is lots of broken intermediaries returning broken
Content-Location headers, but I do not consider that a problem for
making good use of the header. Most of those same intermediaries would
have just as big problems with any extension added.

>        own URI, which may be indicated by a Content-Location in the

Works for me I think..

> I don't see why this keeps coming up.  PUT does not vary.

Probably because Content-Location hasn't been well established so we
keep forgetting about it..

> If you PUT

Or 1b) Change the URI into a non-negotiated resource which is what I
suppose will happen on most servers..

>        looking at the Accept* headers.

Ok. Good to have that cleared out.

> in all variants.  Otherwise, PATCH does not have uniform semantics.

Makes perfect sense.

Regards
Henrik

---

From: James M Snell <[email-masked]>
Date: Mon, 06 Aug 2007 17:34:45 -0700

> enough to make people use it as specified.  *shrug*

Or it won't be enough and people still won't use it as specified.  I'm
not saying it's a good thing, but a new status code is likely the more
reliable of the two options.

- James

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 6 Aug 2007 19:24:03 -0700

On Aug 6, 2007, at 2:43 PM, Julian Reschke wrote:
> Cache-Control applies to the response. What the proposal is about  
> is to enable the server to say that

Cache-control is a general header (both a request and response header).
Its scope in a response is the same as ETag.

> So these are really different things.

No, they aren't different things.  Both refer to the same content,
with the same freshness requirements, so there is no situation in
which the resource owner would need to assign them different values.
We simply define cache-control to apply to both and we are done.
That is exactly how I would interpret such a received response today,
that includes both content-location and cache-control, without any
changes to 2616.  All we would be changing is the documentation.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 6 Aug 2007 19:36:40 -0700

> reliable of the two options.

I don't see how we can guess that.  The existing mechanism is already
deployed, which means no technology changes other than the preexisting
task of fixing broken configurations.  Content-Location has a lot of
value outside HTTP (think mail gateways and external archives), so
there are side benefits to using it correctly.

After all, there were many good reasons for us choosing this design
in the first place, and I really don't have any confidence that the
folks who currently incorrectly implement content-location will have
any more success correctly implementing a new status code or headers.
In my opinion, choosing a new status code for 2xx (content in response)
is no more likely to succeed than 200+Content-Location indicating
the same for all methods.  I suggest, however, that any additions to
HTTP need to be proven first by implementations, and it would be very
annoying to deploy a new status code only to find out later that we
didn't need it.  Defining new things is a serious brain tax.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Aug 2007 13:59:26 +0200

Roy T. Fielding wrote:
>> Cache-Control applies to the response. What the proposal is about is 
>> to enable the server to say that
> 

Doesn't compute for me. Example:

When I do a PROPFIND on a WebDAV collection, the DAV:multistatus 
response body represents (in the simple case) the collection membership 
of that collection. That information may be cacheable, and can change 
frequently (if there is authoring going on).

On the other hand, the substitute URL for that response (as proposed in 
the GET-Location proposal) has a much longer lifetime. If the lifetime 
would be the same, a client couldn't use GET *instead* of PROPFIND, and 
that was the main point of the proposal.

> changes to 2616.  All we would be changing is the documentation.

If the cacheability of both is the same, then it can't be used in the 
way the it's being proposed.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Aug 2007 14:05:53 +0200

> Is there really a need to time-limit the substitute URL?

I have to admit I'm not really sure.

> "PROPFIND URI namespace schema".

Yes, one could argue that a 404 response on the substitute URL is the 
signal to go back to the original method and Request-URI. However, that 
would mean that:

- that we loose the ability to use 404 as in the original method (such 
as: the resource is gone, but it may come back), and

- it may become harder to deploy changes in the server software (when 
the substitute URL format changes).

> There is no problem for PROPFIND to define that this Content-Location is

...other than RFC2616 saying it's not permanent?

I'd really prefer not to change this.

> GET's for the same URI (note: the restriction on host is then not

I'm not sure I follow here.

The purpose of the proposal is to expose GETtable resources that 
previously where hidden behind PROPFIND/REPORT/SEARCH and similar 
methods. Once a client learns about these resources, they should behave 
just like any other HTTP resource....

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Aug 2007 14:25:30 +0200

> whether those properties are retrieved via GET propURI or PROPFIND resURI.

I agree that that definition (as seen in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2007JulSep/0199.html>) 
makes sense, although to make it work with PROPFIND/SEARCH/REPORT it 
would also need to include the request *body*.

However, I'm not 100% sure there's consensus for it. The major change 
here is that it takes the request method into account. Code that relies 
on it being method agnostic would break.

(Such as a PROPPATCH with an If-Match header using a cache validator 
previously returned in GET).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Aug 2007 14:29:58 +0200

> enough to make people use it as specified.  *shrug*

 From the discussions over on the Atom mailing list, few people realize 
that Content-Location can be used that way by just looking at the spec.

Let's clarify it.

>       looking at the Accept* headers.

Again, I agree, but that's another aspect of HTTP people get confused 
about, and in this case, I'll blame the spec, not the people trying to 
decipher it.

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 07 Aug 2007 17:25:03 +0200

> previously returned in GET).

?

GET of what? The "original" Request-URI, or the GET-able location
returned by PROPGET?

Both should return the same ETag witch is that of the PROPGET results.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Aug 2007 17:32:05 +0200

> GET of what? The "original" Request-URI, or the GET-able location

The Request-URI.

(It's PROPFIND, not PROPGET)

> Both should return the same ETag witch is that of the PROPGET results.

Why would they return the same ETag?

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 07 Aug 2007 17:46:25 +0200

> (It's PROPFIND, not PROPGET)

Sorry. A bit tired today.

> Why would they return the same ETag?

Because PROPATCH changes the properties, not the "object". But this use
of ETag doesn't fit WebDAV very well..

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Aug 2007 17:57:29 +0200

> of ETag doesn't fit WebDAV very well..

The distinction between a WebDAV resource and its properties is fuzzy.

For instance, some "live properties" depend on the HTTP resource (such 
as DAV:getetag :-), others depend on locks.

Then, properties may be computed out of the resource (think extracting 
the <title> from HTML). The reverse may be true as well, so a PROPPATCH 
*can* affect "the object".

Things are further complicated by the fact that there are many kinds of 
PROPFINDs; the result depends both on request headers (such as Depth) 
and the request body. In theory, each unique combination of these may 
refer to a different variant (using Roy's new definition), and use a 
separate space of ETags.

So, in general, PROPFIND (under Roy's definition of "requested variant") 
wouldn't return the same ETag as GET (for the same Request-URI).

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 7 Aug 2007 10:54:02 -0700

On Aug 7, 2007, at 8:57 AM, Julian Reschke wrote:

> For instance, some "live properties" depend on the HTTP resource  
> (such as DAV:getetag :-), others depend on locks.

And one very fun property implemented in MS software depends on *the  
URL used to access the resource* -- the property value is "the last  
segment of the URL used".

-- lisa

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 7 Aug 2007 11:20:54 -0700

On Aug 7, 2007, at 5:25 AM, Julian Reschke wrote:
> I agree that that definition (as seen in <http://lists.w3.org/ 
> Archives/Public/ietf-http-wg/2007JulSep/0199.html>) makes sense,  
> although to make it work with PROPFIND/SEARCH/REPORT it would also  
> need to include the request *body*.
>
> However, I'm not 100% sure there's consensus for it. The major  
> change here is that it takes the request method into account. Code  
> that relies on it being method agnostic would break.
>
> (Such as a PROPPATCH with an If-Match header using a cache  
> validator previously returned in GET).

I am really not interested in doing contortions for the sake of
WebDAV's broken model.  WebDAV is, and always will be, a poor man's
exception to every rule of HTTP.  That's what the WG insisted on,
even when I explained why it wouldn't survive the next generation.

The only reason that such a request is valid is because a PROPPATCH
is generally intended for a specific representation, so testing the
If-Match on the body ETag is good enough for what PROPPATCH intends.
If the WebDAV server chooses to use the same entity-tag for both
properties and representation, then both the above request and my
proposal will work fine.  If not, then you should be using the ETag
returned on the PROPFIND response, not a GET response.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Aug 2007 20:47:00 +0200

> returned on the PROPFIND response, not a GET response.

Roy,

the reason why people may do strange things we ETags is IMHO not the 
fault of WebDAV, but the wording of RFC2616. That's why I've been 
pushing for clarifications of "requested variant" and ETag in write 
operations for almost two years now.

Don't shoot the messenger.

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 07 Aug 2007 22:23:51 +0200

> wouldn't return the same ETag as GET (for the same Request-URI).

Correct. It would return the same ETag as a GET for the "GET location"
of the same PROPFIND results.

Regards
Henrik

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 7 Aug 2007 15:33:39 -0700

> I have to admit I'm not really sure.

I don't even understand why such a thing would be useful.  All URLs
are permanent -- it is only the representations that change over time.

> Yes, one could argue that a 404 response on the substitute URL is  
> the signal to go back to the original method and Request-URI.  
> However, that would mean that:
>
> - that we loose the ability to use 404 as in the original method  
> (such as: the resource is gone, but it may come back), and
>
> - it may become harder to deploy changes in the server software  
> (when the substitute URL format changes).
>

I don't know if this is just a language issue or bad grammar within
the spec, but I know for a fact that isn't what was intended or in
practice.  What the spec is supposed to say is that the new location
is not a permanent replacement for the URI that was used in the original
request.  In other words, the recipient cannot assume that

    PROPFIND oldURI  ==  PROPFIND newURI

That statement has nothing whatsoever to do with the permanence of
newURI as an identifier for the new resource.  If you just think of
how C-Loc is used most commonly -- within content negotiation -- that
should be clear.  newURI is ideally the permanent identifier for the
variant that directly corresponds to the provided representation
(as included in the entity).  In other words, Content-Location
is exactly what you want.  The only thing you need to add is a
clarification that the provided general/response-header fields are
also applicable to that Content-Location as if it had been a GET
request, but only when the security consideration regarding cache
poisoning can be reasonably avoided.

....Roy

---

From: James M Snell <[email-masked]>
Date: Wed, 08 Aug 2007 09:35:20 -0700

Well, the good thing is that there is no particular reason to rush this
particular method to standardization.  We definitely need to get some
folks implementing this.  Dependent entirely on how much time I'm able
to etch out, I'm hoping to have a simple implementation of a
PATCH-enabled atompub server available.  With that, I can enable both
approaches (200+Content-Location and the 209 response) and will
hopefully be able to start evaluating them.

That said, the primary rationale behind 209 is not that
200+Content-Location wouldn't work; it's that 200+Content-Location is
somewhat amiguous and error-prone.  If there are ways of resolving those
issues, then great.

- James

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Aug 2007 14:58:56 +0200

> are permanent -- it is only the representations that change over time.

The substitute URL is created/supported by the server. In general, it 
shouldn't change. In practice, changes of server code/config *do* 
happen, which may cause the substitute URL not to be the substitute anymore.

One can argue that this shouldn't happen frequently (which I agree 
with), but the question remains whether the protocol should allow 
specifying a lifetime (or alternatively, how a client is supposed to 
find out that it needs to obtain a new substitute).

>> signal to go back to the original method and Request-URI. However, 
>> that would mean that:
>>

What I'm looking for is a way to tell the client that for subsequent 
requests

      PROPFIND oldURI == GET newURI

If the validity of this information is restricted to the "next" 
requests, it doesn't solve the problem I want to solve.

So does Content-Location allow that?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Aug 2007 15:15:08 +0200

>       own URI, which may be indicated by a Content-Location in the

The problems that I see here are:

1) for PROPFIND and friends, not only request header fields and method 
names, but also the request *body* select the variant -- I don't have a 
problem with that, but it should be spelled out.

2) a bigger problem IMHO is that allowing this additional level of 
indirection creates different classes of entity tags. Example: Entity 
tags returned in GET/HEAD/PUT/POST/DELETE can only be used for 
GET/HEAD/PUT/POST/DELETE. Similarly, for PROPFIND/PROPPATCH. I'm a bit 
concerned about that.

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 17 Aug 2007 18:32:44 -0700

On Aug 17, 2007, at 6:15 AM, Julian Reschke wrote:
> 1) for PROPFIND and friends, not only request header fields and  
> method names, but also the request *body* select the variant -- I  
> don't have a problem with that, but it should be spelled out.

I have lots of problems with that, though I don't think it impacts
the definition of variant. What does PROPFIND specify in the body?

> indirection creates different classes of entity tags. Example:  
> Entity tags returned in GET/HEAD/PUT/POST/DELETE can only be used  
> for GET/HEAD/PUT/POST/DELETE. Similarly, for PROPFIND/PROPPATCH.  
> I'm a bit concerned about that.

It is already true in practice -- people just aren't aware of it, or
are inserting fake etags just to comply with nonsense.  From my
perspective, PROPFIND/PROPPATCH are incredibly bad protocols within
a protocol (essentially, search and replace tunneled through other
resource interfaces).  I don't need HTTP to make sense of them any
more than I need it to make sense of POST requests.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Sat, 18 Aug 2007 11:38:16 +0200

Roy T. Fielding wrote:
>> names, but also the request *body* select the variant -- I don't have 
>> a problem with that, but it should be spelled out.
> 

For instance, the body specifies what properties to return. Thus, as far 
as I can tell, it needs to be taken into account in this definition, 
otherwise it won't help.

> more than I need it to make sense of POST requests.

The whole point of my proposal is to build a bridge to "proper" 
resources, that can be retrieved using GET, and manipulated using PUT/PATCH.

The discussion about the semantics of "requested variant" is needed 
independently of that, because even for PUT lots of people disagree.

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 18 Aug 2007 11:19:27 -0700

On Aug 18, 2007, at 2:38 AM, Julian Reschke wrote:
> For instance, the body specifies what properties to return. Thus,  
> as far as I can tell, it needs to be taken into account in this  
> definition, otherwise it won't help.

Generally speaking, a subset of properties should have the same etag
as the whole set of properties.  I was wondering if the body also
did resource selections, like depth=infinity.

>>> 2) a bigger problem IMHO is that allowing this additional level  
>>> of indirection creates different classes of entity tags. Example:  

Right, but you are also trying to make the HTTP model make sense
for a method that intentionally violates the HTTP model.  It is
easier just to say that PROP* is a search method that is separate from
the HTTP model.

> independently of that, because even for PUT lots of people disagree.

Right, that's the only thing I wanted to address in the definition,
though it would also be nice to have a meaningful way of discussing
why variants effect the response selection algorithm in general.

I wish I had just removed server-side content negotiation from HTTP
when we had the chance (all of these problems are solved by 300).

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Sat, 18 Aug 2007 20:28:14 +0200

Roy T. Fielding wrote:
>> For instance, the body specifies what properties to return. Thus, as 
>> far as I can tell, it needs to be taken into account in this 

...I don't think this is the case. It would be true if the only 
properties would be "dead" properties, but there are also live 
properties, and furthermore things a more complicated with REPORT and 
SEARCH.

For instance, I would expect that the following properties are handled 
completely separately, thus will have differently behaving etags:

- DAV:get* (such as DAV:getcontenlength), which will be tied to the 
requested variant upon GET,

- DAV:activelocks (depending on the locking subsystem), and

- DAV:displayname (stored somewhere else).

(I picked simple ones that are indeed implemented in Apache/httpd).

*PROPFIND* doesn't do resource selection depending on the body, but 
other methods such as REPORT and SEARCH do.

>>>> for GET/HEAD/PUT/POST/DELETE. Similarly, for PROPFIND/PROPPATCH. I'm 
>>>> a bit concerned about that.

Whether it's intentional or not I'll not comment on (how would I know?). 
As far as I can tell from what's stated, PROPFIND does not violate that 
model, though.

Best regards, Julian