Subject: [Bug 12] Destination header "consistent"

From: [email-masked]
Date: Wed, 19 Oct 2005 04:47:14 -0700

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Oct 2005 14:06:27 +0200

Proposed resolution for 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12>:

This is about section 8.1.3, which currently says:

"8.1.3 Use of Location header in responses

When the Location header is used in a response, it is used by the server 
to indicate the preferred address for the target resource of the 
request. Whenever the server has a preferred address, it should use that 
address consistently. This means that when a response contains a 
Location header, all the URLs in the response body (e.g. a Multi-Status) 
should be consistent (most importantly, should use the same host and 
port)." 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.8.1.3>)

I really have no idea what this is about. HTTP (RFC2616) defines 
"Location" as:

"14.30 Location

The Location response-header field is used to redirect the recipient to 
a location other than the Request-URI for completion of the request or 
identification of a new resource. For 201 (Created) responses, the 
Location is that of the new resource which was created by the request. 
For 3xx responses, the location SHOULD indicate the server's preferred 
URI for automatic redirection to the resource. The field value consists 
of a single absolute URI.

        Location       = "Location" ":" absoluteURI

An example is:

        Location: http://www.w3.org/pub/WWW/People.html

     Note: The Content-Location header field (Section 14.14) differs 
from Location in that the Content-Location identifies the original 
location of the entity enclosed in the request. It is therefore possible 
for a response to contain header fields for both Location and 
Content-Location. Also see Section 13.10 for cache requirements of some 
methods." 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.30>)

Unless somebody can explain what the connection between URLs in response 
bodies and the "Location" response header is, I'd suggest to get rid of 
this paragraph (patch attached).

Best regards, Julian

--- draft-ietf-webdav-rfc2518bis-latest.xml	2005-10-19 12:59:48.000000000 +0100
+++ draft-ietf-webdav-rfc2518bis-latest.12.xml	2005-10-19 12:59:34.000000000 +0100
@@ -1144,18 +1144,6 @@
       </t>
     </section>  
     
-    <section title="Use of Location header in responses">
-      <t>
-   When the Location header is used in a response, it is used by the 
-   server to indicate the preferred address for the target resource of 
-   the request.  Whenever the server has a preferred address, it should 
-   use that address consistently.  This means that when a response 
-   contains a Location header, all the URLs in the response body (e.g. 
-   a Multi-Status) should be consistent (most importantly, should use 
-   the same host and port). 
-      </t>
-    </section>
-    
     <section title="Required Response Headers: Date">
       <t>
    Note that HTTP 1.1 requires the Date header in all responses if

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 22 Oct 2005 00:21:14 -0700

Another ignorant questions but ... Do existing servers include Locations
headers. For any generic header X, if servers use it or clients expect it,
then I would hope the spec talked about what needed to be in header X. If no
one uses header X (and sound like you are saying it is hard to imagine
anyone uses since no one knows what it means) then the spec should ignore it
or say not to use it.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 22 Oct 2005 10:26:05 +0200

> anyone uses since no one knows what it means) then the spec should ignore it

As far as I can tell, returning a "Location" response header with status 
207 is completely meaningless, and I'm not aware of any server doing that.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Sat, 22 Oct 2005 10:44:54 -0700

Trying to fill in a little background here: we've discussed this 
related issues before, from June 22 to 26, 2003 and Oct 9 2003.  I 
think part of what we concluded was that if a resource that is 
mentioned in a PROPFIND response would normally return a Location 
header (if you did a HEAD to that resource alone) we needed to find a 
way to return the same info inside the PROPFIND response. So we 
discussed use of 302/303 and a <DAV:location> element to provide the 
information that would have been in the Location header, all inside the 
207 response.

But a slightly different case: if *all* of the resources had been 
redirected (if the target collection itself or a parent had been 
redirected) then one single Location header for the entire response 
might work for the whole shebang.  Thus, I don't agree that returning 
207 with a Location header is meaningless.  (I have no reason to 
disagree with the assertion that existing implementations probably 
don't do that, though).

It might well be premature optimization, however.  The "dumber" way to 
handle this case -- when the request is to a collection that has been 
moved/redirected -- is simply to return the appropriate 300 level 
response and Location and make the client repeat the request against 
the new URL.  Two roundtrips, but probably not a case worth optimizing 
for, because we'd have to define either how to combine the Location 
header with relative URLs inside the response, or how the Location 
header must be consistent with absolute URLs inside the response.

Is there consensus that the Location header MUST NOT be used with 207?  
(and while we're at it, should we generalize to all status responses 
besides 201 and 301, 302, 303, 305, 307?)

Lisa

On Oct 22, 2005, at 1:26 AM, Julian Reschke wrote:

> As far as I can tell, returning a "Location" response header with 
> status 207 is completely meaningless, and I'm not aware of any server 
> doing that.
>
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 22 Oct 2005 20:04:49 +0200

Lisa Dusseault wrote:
> Trying to fill in a little background here: we've discussed this related 
> issues before, from June 22 to 26, 2003 and Oct 9 2003.  I think part of 

For the former time range, I'm not sure what messages you're referring 
to (URL?). For the latter, this was about DAV:location elements in 
DAV:multistatus (see 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/thread.html#35>).

> what we concluded was that if a resource that is mentioned in a PROPFIND 
> response would normally return a Location header (if you did a HEAD to 
> that resource alone) we needed to find a way to return the same info 
> inside the PROPFIND response. So we discussed use of 302/303 and a 
> <DAV:location> element to provide the information that would have been 
> in the Location header, all inside the 207 response.

That's all true, but what does this have to do with what the spec 
currently says? It talks about some interaction of a "Location" response 
header and a multistatus response body (on the very same message), and I 
really don't get what this has to do with the issue mentioned above.

> redirected) then one single Location header for the entire response 

That's a different situation, described in 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-13.html#redirect.references.to.collections>. 
As a redirect reference resource is not a collection, a PROPFIND on it 
with no Redirect-specific request headers simply would return in a 302 
status, just like GET or HEAD.

> disagree with the assertion that existing implementations probably don't 
> do that, though).

The nature of a redirect resource is that it redirects to a different 
URL, using 3xx and Location header. Applying PROPFIND to a redirect gets 
you a 3xx and a Location header, not a 207 and multistatus.

The REDIRECT spec defines an extension so that you can PROPFIND the 
properties of the redirect, instead of being redirected. That still 
doesn't make a redirect a WebDAV collection.

On the other hand, a WebDAV collection that *contains* redirects will 
respond with 207/multistatus to a PROPFIND.

> response and Location and make the client repeat the request against the 
> new URL.  Two roundtrips, but probably not a case worth optimizing for, 
> because we'd have to define either how to combine the Location header 
> with relative URLs inside the response, or how the Location header must 
> be consistent with absolute URLs inside the response.

This sounds a bit like you want to re-invent redirects altogether. 
Applying an HTTP method to a redirect causes a 3xx with a Location 
header. That's it, unless the client uses specific extensions to request 
different behaviour (one approach is defined in the REDIRECT spec).

> besides 201 and 301, 302, 303, 305, 307?)

Lisa, it seems that whatever we discuss, you try to turn this into a 
discussion about even more spec text. RFC2518bis doesn't need to say 
anything about it. Whatever RFC2616 already says and a future WebDAV 
REDIRECT spec will say is sufficient.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Sat, 22 Oct 2005 11:20:30 -0700

> REDIRECT spec will say is sufficient.

You say that as though it's a bad thing!  Whenever we discuss or 
disagree on the mailing list, I find that's a good case for narrowing 
down what can be done in implementations of RFC2518bis; to reduce 
variety between implementations, improve interoperability and have a 
complete spec that doesn't send people running to the mailing list all 
too often.

We can at least think and talk about the issue -- if we *do* come to 
consensus that Location header is not appropriate in 207 responses (or 
other new response codes defined by WebDAV, or new methods defined by 
WebDAV) then any of that would be good information to add to the spec.  
OTOH if we come to consensus that we shouldn't restrict Location header 
use but leave it undefined on most response types, I hope there's a 
good reason for that which would come out in a discussion.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Sat, 22 Oct 2005 20:42:35 +0200

> You say that as though it's a bad thing!  Whenever we discuss or 

Yes, as a matter of fact I think it's a bad thing. We are revising 
RFC2518, which to me means

- fixing bugs (examples, typos)
- removing stuff nobody does implement (such as DAV:propertybehaviour)
- simplify things that were too complex in the first place (lock-null 
resources come to mind)
- removing stuff that's not need today anymore (XML namespace 
explanations, UUID generation instructions...)
- update references
- add stuff that we agree was missing (DAV:lockroot...)

This may not be complete, but it should cover most cases.

Just adding prose without no actual need for it IMHO is a bad idea. Do 
that in FAQs, Blogs, online resources, implementor guides, books, whatever.

> complete spec that doesn't send people running to the mailing list all 

"Narrowing down" means a change of the spec. As far as I can tell, there 
is no need to change the spec. If you feel there is a need, please 
explain way (interop problem???).

> WebDAV) then any of that would be good information to add to the spec.

I disagree. RFC2616 defines what the "Location" header is for, and any 
attempt to go further than that without practical reasons IMHO would be 
the wrong thing to do.

> use but leave it undefined on most response types, I hope there's a good 
> reason for that which would come out in a discussion.

We can (and will) discuss whatever is raised here. I just dont't see how 
this discussion helps us in any way revising RFC2518. As a matter of 
fact, it slows us down, because it distracts us from the things that 
*are* on the issues list.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 23 Oct 2005 17:44:16 -0400

I agree with all of Julian's points.

We have a large number of real issues to deal with.

Let's get those taken care of before we waste any more time on debating
whether it improves or damages the specification by adding in arbitrary
amounts of additional "explanatory" text to an already overly long 
specification.

Cheers,
Geoff

> > use but leave it undefined on most response types, I hope there's a 
good

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 26 Oct 2005 20:27:23 -0700

> This may not be complete, but it should cover most cases.

We are also clarifying the Spec so that implementers end up implementing
versions that do interoperate.

> that in FAQs, Blogs, online resources, implementor guides, books, whatever.

There is a fine line here. Someone skill in the art should be able to
correctly implement this by just reading the Spec and the documents it
normatively references. That does not mean we should right a basic tutorial
on how it all works or the sort of material that might be covered in WebDAV
book. It's a fine line to draw, but I tend to ask myself, if your average
implementer has a 20% chance of doing the wrong thing, you probably need
more advice or notes to keep them on the right path.

That is my somewhat philosophic answer, however, I have a far more pragmatic
thing you should keep in mind. The IESG has to read this, and if it makes no
sense to them, pain and suffering will ensue. This does not mean just the
apps ADs with an amazing background in the area has to read it, it means
that someone from a completely different area (say security) has to read it,
and understand it well enough to evaluate if it has significant issues. And
they are unlikely to read FAQs, Blogs etc because they are too busy.

In the case you are taking about here, I have no idea what the right line is
and I'm not supporting Lisa's or Julian's or anyone else opinion on it. I'm
just pointing out that this is not black or white but is one of the many
things where the WG will have to find some sort of reasonable balance.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 26 Oct 2005 20:30:34 -0700

> We have a large number of real issues to deal with.

That is definitely true. And I agree with Geoffrey we have to focus on the
ones that would be a show stopper to getting agreement on the final ASCII
text that we plan to send to IESG.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 27 Oct 2005 14:48:51 +0200

Cullen Jennings wrote:
> ...

a) Yes, but...:

b) Even if it's not about RFC2518 itself, but a normatively referenced 
spec? That is, do explanations/clarifications for HTTP belong into 
RFC2518bis, or RFC2616bis?

> they are unlikely to read FAQs, Blogs etc because they are too busy.

Yes, and if information is *needed*, it should be in the spec.

On the other hand, we're revising a spec that already has been accepted 
once. I would think it would make a lot of sense to keep changes to the 
minimum needed to achieve our goals. As a matter of fact, RFC2518 has 
had more contributors and reviewers than we can ever hope to find for 
RFC2518bis, so my proposal is to avoid changes unless they clearly 
enhance the spec.

> things where the WG will have to find some sort of reasonable balance.

Back to this issue:

1) I'm not aware of any interop problems.

2) I'm not aware of anybody having asked about this.

3) I don't see any benefit in RFC2518bis making statements about this, 
even if we *did* agree on what to say.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 27 Oct 2005 09:53:21 -0400

I agree with Julian's points, and would add that there is significant
experience that shows that these "helpful hints" can end up being the
greatest source of implementation confusion.  A prime example is the
the suggestion that "MOVE" be thought of as a "COPY followed by a DELETE".
People confuse these hints with normative text, and then base their
implementations on these hints rather than on the normative text.
So it is not enough to say "would this text answer this particular 
question",
but also have to check "can this text be misinterpreted in a way that
conflicts with the normative text".  And if the spec is already very long,
each new paragraph introduces the chance that reader fatigue will prevent
them from ever getting to the normative text, because of the amount of
intervening non-normative text.

Cheers,
Geoff

Julian wrote on 10/27/2005 08:48:51 AM:

> > That is my somewhat philosophic answer, however, I have a far 
morepragmatic

---

From: Jim Whitehead <[email-masked]>
Date: Thu, 27 Oct 2005 16:50:06 -0700

Julian writes:
> 3) I don't see any benefit in RFC2518bis making statements about  
> this, even if we *did* agree on what to say

I have just read through this entire thread, and I agree with his  
statement above, and the conclusion Julian reached in:
http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0294.html

Specifically:

* I don't think there is a compelling need to disallow Location and 207
* I don't think we need any special mechanism for handling 3xx within  
a PROPFIND
* I think it's fine if a client needs to retry a PROPFIND request if  
it receives a 3xx response

I feel a slight desire to add a 3xx response to one of the PROPFIND  
207 response examples in the text, but could live without it.

Unless others chime in, I think we're seeing rough consensus for  
removing the current 8.1.3, whose text is described in Bug 12 within  
Bugzilla:
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12

- Jim

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 27 Oct 2005 23:17:26 -0400

+1

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 28 Oct 2005 14:17:46 -0700

Well I do agree on removing this section, and that supporting Location 
with 207 responses isn't necessary.   That means there's some text 
early in section 12 that can go away, as well.

However, without those pieces of text, the use of the Location header 
with 207 responses becomes undefined, and that always makes me feel 
uncomfortable.    Server implementors won't know for sure if they can 
use the Location header, it seems logical that it might work but as 
we've seen there are some subtleties in how the client might interpret 
that.  Clients are probably not prepared to handle it.  So I propose 
that we include text to be clear that the Location header SHOULD NOT 
appear in certain responses.

I'm sensitive to the worry of preventing extensions but surely there's 
some way of dealing with that.  An extension can override "SHOULD" 
level requirements, or we could come up with some "exception" 
language... as in "servers SHOULD NOT return a Location header in these 
responses unless the client has some way to interpret that header."

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Oct 2005 23:35:20 +0200

Lisa Dusseault wrote:
> with 207 responses isn't necessary. That means there's some text early 
> in section 12 that can go away, as well.
> 
> uncomfortable. Server implementors won't know for sure if they can use 

The "Location" header is defined by RFC2616. Multistatus response bodies 
are defined in RFC2518. Are you saying that those definitions are 
incompatible? That would be a bug. If they aren't, there's nothing that 
needs to be fixed.

> the Location header, it seems logical that it might work but as we've 
> seen there are some subtleties in how the client might interpret that. 
> Clients are probably not prepared to handle it. So I propose that we 
> include text to be clear that the Location header SHOULD NOT appear in 
> certain responses.

Do you have any evidence of interoperability problems because RFC2518 
doesn't say anything about this?

> some way of dealing with that. An extension can override "SHOULD" level 
> requirements, or we could come up with some "exception" language... as 
> in "servers SHOULD NOT return a Location header in these responses 
> unless the client has some way to interpret that header."

-1.

Please define what the problem is with what RFC2518 and RFC2616 
currently say. We can then discuss whether there's a need to fix one of 
them.

Best regards, Julian

---

From: Jim Whitehead <[email-masked]>
Date: Fri, 28 Oct 2005 14:38:38 -0700

Lisa writes:

> However, without those pieces of text, the use of the Location  
> header with 207 responses becomes undefined, and that always makes  
> me feel uncomfortable.    Server implementors won't know for sure  
> if they can use the Location header, it seems logical that it might  
> work but as we've seen there are some subtleties in how the client  
> might interpret that.  Clients are probably not prepared to handle  
> it.  So I propose that we include text to be clear that the  
> Location header SHOULD NOT appear in certain responses.

The HTTP specification generally doesn't explain all interactions of  
methods, headers, and response codes. Location only has defined  
semantics for certain response codes in HTTP.

On the other hand, the HTTP spec. isn't necessarily such a paragon of  
good writing that we should strive to emulate it.

My solution to this issue is to add the text:

"Use of the Location header with the methods and response codes  
defined in this specification is intentionally undefined."

And leave it at that. This lets clients know they can't depend on the  
feature, and lets servers know they probably shouldn't go there. But,  
if a later spec. does add something here (like a refined REDIRECT  
spec.), then the door is left open for new behavior.

Can we please close this issue?

- Jim

>
> I'm sensitive to the worry of preventing extensions but surely  
> there's some way of dealing with that.  An extension can override  
> "SHOULD" level requirements, or we could come up with some  
> "exception" language... as in "servers SHOULD NOT return a Location  
> header in these responses unless the client has some way to  
> interpret that header."
>
> Lisa
>

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 28 Oct 2005 14:49:14 -0700

That's pretty concise and still useful.  I can live with that.

Lisa

On Oct 28, 2005, at 2:38 PM, Jim Whitehead wrote:

>> we've seen there are some subtleties in how the client might  
>> interpret that. Clients are probably not prepared to handle it. So I  
>> propose that we include text to be clear that the Location header  
>> SHOULD NOT appear in certain responses.
>> header in these responses unless the client has some way to interpret  
>> that header."
>>
>> Lisa
>>
>>>  >
>>>  > >
>>>  >
>>>  > Julian writes:
>>>  > > Back to this issue:
>>>  > >
>>>  > > 1) I'm not aware of any interop problems.
>>>  > >
>>>  > > 2) I'm not aware of anybody having asked about this.
>>>  > >
>>>  > > 3) I don't see any benefit in RFC2518bis making statements about
>>>  > > this, even if we *did* agree on what to say
>>>  >
>>>  > I have just read through this entire thread, and I agree with his
>>>  > statement above, and the conclusion Julian reached in:
>>>  >  
>>>  >
>>>  > Specifically:
>>>  >
>>>  > * I don't think there is a compelling need to disallow Location  
>>> and 207
>>>  > * I don't think we need any special mechanism for handling 3xx  
>>> within
>>>  > a PROPFIND
>>>  > * I think it's fine if a client needs to retry a PROPFIND request  
>>> if
>>>  > it receives a 3xx response
>>>  >
>>>  > I feel a slight desire to add a 3xx response to one of the  
>>> PROPFIND
>>>  > 207 response examples in the text, but could live without it.
>>>  >
>>>  > Unless others chime in, I think we're seeing rough consensus for
>>>  > removing the current 8.1.3, whose text is described in Bug 12  
>>> within
>>>  > Bugzilla:
>>>  > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12
>>>  >
>>>  > - Jim
>>>  >
>>>  >
>>>  >
>>>  >

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 28 Oct 2005 14:58:33 -0700

One thing I noticed when checking this against and editing the text  
(sometimes this turns up new observations):   We actually use the  
Location header in response to a MOVE request, in section 8.9.5 of  
RFC2518.   Yet there's no explanation for this -- the text around the  
example doesn't indicate whether the server could have chosen a  
different destination URL (which seems very harmful to interoperability  
to me) or, if not, why the Location header is even needed.

8.9.5 Example - MOVE of a Non-Collection

     This example shows resource
     http://www.ics.uci.edu/~fielding/index.html being moved to the  
location http://www.ics.uci.edu/users/f/fielding/index.html. The  
contents of the destination resource would have been overwritten if the  
destination resource had been non-null. In this case, since there was  
nothing at the destination resource, the response code is 201  
(Created).

     >>Request

     MOVE /~fielding/index.html HTTP/1.1
     Host: www.ics.uci.edu
     Destination: http://www.ics.uci.edu/users/f/fielding/index.html

     >>Response

     HTTP/1.1 201 Created
     Location: http://www.ics.uci.edu/users/f/fielding/index.html

----

What if I remove the header from the response example, in addition to  
Jim's suggested change?

Lisa

On Oct 28, 2005, at 2:49 PM, Lisa Dusseault wrote:

>>> me feel uncomfortable. Server implementors won't know for sure if  
>>> they can use the Location header, it seems logical that it might  
>>> it. So I propose that we include text to be clear that the Location  
>>> header SHOULD NOT appear in certain responses.
>>>>  > * I think it's fine if a client needs to retry a PROPFIND  
>>>> request if

---

From: Jim Whitehead <[email-masked]>
Date: Fri, 28 Oct 2005 15:13:17 -0700

> What if I remove the header from the response example, in addition  
> to Jim's suggested change?
>

Urk, bad idea.

The use of Location with MOVE is to be consistent with the semantics  
of the 201 response code.

So, the suggested text has to be more precise. Perhaps:

"The use of the Location header with the 207 status code is  
intentionally undefined."

However, even this I'm starting to feel is a bad idea. Why do we stop  
at Location? Why not create a table with all HTTP headers and state  
whether they should be used with 207?

- Jim

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 28 Oct 2005 15:23:34 -0700

> of the 201 response code.

I read this a little differently than you -- I don't see that Location 
is REQUIRED with the 201 response code.  So I don't see a problem with 
leaving it out of a 201 Created response to a MOVE, but I'm not adamant 
either way.

> whether they should be used with 207?
Indeed.  It's certainly more work, but this kind of thing can be 
extremely valuable to implementors. As we can see from the discussion 
over the list of response codes that could and couldn't be used in 207 
responses, it's a fine line to walk and quite possible to overspecify.  
Perhaps if we had a table where many of the cell values were simply 
"undefined" instead of "MUST NOT use" we'd have a better compromise...

Lisa

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 28 Oct 2005 15:26:50 -0700

> of the 201 response code.
Tacking on to my previous comment where I said I didn't think Location 
was REQUIRED with 201...  note that in RFC2518, we had an example of 
MKCOL, where the response was 201 Created without a Location header:

8.3.3 Example - MKCOL

     This example creates a collection called /webdisc/xfiles/ on the 
server www.server.org.

     >>Request

     MKCOL /webdisc/xfiles/ HTTP/1.1
     Host: www.server.org

     HTTP/1.1 201 Created

-- Lisa

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 28 Oct 2005 23:24:43 -0400

+1 for either Jim's suggested text or saying nothing,
and +1 that we then close this issue.

Cheers,
Geoff

Jim wrote on 10/28/2005 05:38:38 PM:

> On the other hand, the HTTP spec. isn't necessarily such a paragon 
> of good writing that we should strive to emulate it.
> 
> And leave it at that. This lets clients know they can't depend on 
> the feature, and lets servers know they probably shouldn't go there.
> But, if a later spec. does add something here (like a refined 
> REDIRECT spec.), then the door is left open for new behavior.
>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 29 Oct 2005 10:25:21 +0200

Jim Whitehead wrote:
> "Use of the Location header with the methods and response codes defined 
> in this specification is intentionally undefined."

No, that's completely incorrect. It's defined in RFC2616, and what 
RFC2616 says also applies to WebDAV. For instance, it's absolutely 
well-defined what it means to get a 302 + Location header upon PROPFIND.

> feature, and lets servers know they probably shouldn't go there. But, if 
> a later spec. does add something here (like a refined REDIRECT spec.), 
> then the door is left open for new behavior.
> 

As far as I can tell, the simplest way to close this issue is to revert 
back to what RFC2518 says.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 29 Oct 2005 10:28:03 +0200

Lisa Dusseault wrote:
> (sometimes this turns up new observations): We actually use the Location 
> header in response to a MOVE request, in section 8.9.5 of RFC2518. Yet 
> there's no explanation for this -- the text around the example doesn't 
> indicate whether the server could have chosen a different destination 
> URL (which seems very harmful to interoperability to me) or, if not, why 
> the Location header is even needed.
 > ...

RFC2616 recommends to use the Location header when a new resource is 
created:

<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.30>

That is, if you consider MOVE as a sequence of COPY-then-DELETE, this is 
exactly the right thing to do.

As I personally prefer MOVE to work differently, I'd be happy to change 
that example, but that's *really* a different issue from what we were 
discussing here.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 29 Oct 2005 10:29:28 +0200

Jim Whitehead wrote:
> ...
> However, even this I'm starting to feel is a bad idea. Why do we stop at 
> Location? Why not create a table with all HTTP headers and state whether 
> they should be used with 207?
> 
> - Jim

Hey! I see light at the end of the tunnel :-)

Generally, the set of things we do not define is open-ended. I'm against 
making statements about these things, unless they clearly result in 
confusion and interop problems.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 29 Oct 2005 10:32:55 +0200

>     MKCOL /webdisc/xfiles/ HTTP/1.1

Lisa,

would you *please* read the sections from RFC2616 that define this?

Again, from 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.30>:

"The Location response-header field is used to redirect the recipient to 
a location other than the Request-URI for completion of the request or 
identification of a new resource."

The location isn't different, so no new URI is needed.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Sat, 29 Oct 2005 08:49:09 -0700

On Oct 29, 2005, at 1:32 AM, Julian Reschke wrote:

>> Tacking on to my previous comment where I said I didn't think 
>> Location was REQUIRED with 201...  note that in RFC2518, we had an 
>> example of MKCOL, where the response was 201 Created without a 
>> Location header:
>> 8.3.3 Example - MKCOL
> "The Location response-header field is used to redirect the recipient 
> to a location other than the Request-URI for completion of the request 
> or identification of a new resource."
>

Julian,  I have read RFC2616.  I read the relevant section immediately 
before posting which is why I thought that Location was probably not 
required with 201 Created, for the reasons you state.  If you think 
we're saying something different, *please* explain why.

Lisa

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 30 Oct 2005 11:53:15 -0800

> and +1 that we then close this issue.

So I am a client implementer, should I do anything with the Location header
in a 207 or should I just always ignore it?

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Oct 2005 23:56:29 +0100

The first part is for redirects (3xx), the second one for creation of 
resources (201). So right now HTTP doesn't seem to define anything for 
other response codes, so a recipient can ignore it. However, future 
revisions of RFC2616 (or other protocol extensions) may want to use it 
in more scenarios, so AFAIK we should *not* say anything more here.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 31 Oct 2005 07:16:00 -0500

You would do the same as what you would always do with a Location
header in a response, i.e., use the URL specified in the Location header
the next time you wanted to apply a method to the resource.

Cheers,
Geoff

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 31 Oct 2005 10:53:17 -0800

Thanks - Well if that's the case, seem like an argument that everything that
needs saying has already been said.

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 31 Oct 2005 13:06:06 -0800

The original question that brought up this issue was how to interpret 
the URLs inside the body of the Multi-Status if there was a Location 
header.  It was unclear to some client implementors
  - should the URLs in the body be relative to the Location header
  - should they be relative to the Request-URI
  - should they be absolute URLs, always, and if so, should they be 
consistent with the Location header or the Request-URI

There was an actual interoperability problem that uncovered this.  Some 
server returned a Location header and a bunch of URLs in the body, that 
used the new location.  The client errored because the client never 
expected to query a Collection for its children and find a bunch of 
URLs that didn't begin with the URL used in the request URI.

Lisa

On Oct 31, 2005, at 10:53 AM, Cullen Jennings wrote:

>
>  Thanks - Well if that's the case, seem like an argument that 
> everything that needs saying has already been said.
>
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Oct 2005 22:16:25 +0100

> the URLs inside the body of the Multi-Status if there was a Location 

Is there any record on the mailing list of this issue? Has anybody ever 
*seen* a 207 with a Location header? That is, why was this question 
asked in the first place?

> - should they be absolute URLs, always, and if so, should they be 

They should be either absolute, or need to be resolved relative to the 
Reuqest-URI. If this is not clear from RFC2518, let's fix that.

> consistent with the Location header or the Request-URI

What does "consistent" mean here? Note that this is the original reason 
why I raised this issue.

> expected to query a Collection for its children and find a bunch of URLs 
> that didn't begin with the URL used in the request URI.

As far as I can tell, that's a server bug. Clients aren't expected to 
handle PROPFIND responses with URLs that identify resources are then the 
one identified by the Request-URI (and its descendants). If a server 
wants to redirect clients, it will have to use a 3xx status code (as 
defined in RFC2616).

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 31 Oct 2005 13:29:00 -0800

On Oct 31, 2005, at 1:16 PM, Julian Reschke wrote:

> Is there any record on the mailing list of this issue? Has anybody 
> ever *seen* a 207 with a Location header? That is, why was this 
> question asked in the first place?
Yes.  At an Interop event.

...
> What does "consistent" mean here? Note that this is the original 
> reason why I raised this issue.

What I meant by "consistent" (and maybe somebody can find a better way 
to word this or we can just define it) was:  In a PROPFIND or PROPPATCH 
response, for the URLs in the body to be consistent with the 
Request-URI, all URLs would all begin with the exact URL used in the 
Request-URI.   I believe the same would be true for MOVE and COPY 
responses -- the URLs would be consistent with the Request URI, not 
with the Destination request header or the Location reply header.

>> There was an actual interoperability problem that uncovered this. 
>> Some server returned a Location header and a bunch of URLs in the 
>> body, that used the new location. The client errored because the 
>> client never expected to query a Collection for its children and find 
>> a bunch of URLs that didn't begin with the URL used in the request 
>> URI.
>
> handle PROPFIND responses with URLs that identify resources are then 
> the one identified by the Request-URI (and its descendants). If a 
> server wants to redirect clients, it will have to use a 3xx status 
> code (as defined in RFC2616).
>
It may be a server bug under some models or readings of RFC2518.  The 
server implementor certainly would have a case for interpreting RFC2518 
as allowing their "solution".  This past week, Geoff seemed to be 
arguing for allowing Location with 207 and not only with 3xx.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Oct 2005 23:05:23 +0100

> Yes.  At an Interop event.

Is there any record on the mailing list of this issue?

> responses -- the URLs would be consistent with the Request URI, not with 
> the Destination request header or the Location reply header.

I still don't see what problem this solves. The URIs appearing in 
multistatus responses should be either absolute, or relative to the 
Request-URI. If, for instance, in a PROPFIND response, a response 
element comes with a URI that after resolving is not descendant of the 
Request-URI, then the server made a mistake. We can of course discuss 
how a client should handle this. Skipping it is one answer, failing the 
whole request is another. In practice it's unlikely to make a difference 
because if a server get's one response element wrong, it's likely to get 
*all of them* wrong.

>>> a bunch of URLs that didn't begin with the URL used in the request URI.
>>
>>

HTTP defines a range of response codes (3xx) for redirects, and defines 
how the Location header can be used to specify new URIs for subsequent 
requests. I think this feature is completely well-defined, and I'm not 
aware of any problems with that.

If a server implementor chooses to use non-3xx response code for a 
redirect, than that's simply outside what HTTP currently defines; and it 
escapes me why somebody would want to invent something new for a feature 
that already exists.

And finally, Geoff wasn't recommending to use 207 with Location, he just 
made a guess about what a client could conceivably do once it get's a 
response like that.

If this was an interop problem at one point of time, I'd like to see the 
details published, or -- if this isn't possible -- hear from client 
implementors who suffered from that problem. Maybe the servers have been 
fixed since then, and the whole issue has gone away.

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 31 Oct 2005 15:31:39 -0800

> Is there any record on the mailing list of this issue?

There is now :-) Sorry, the recursive self referential possibility was just
too good to pass up.

This email was definitely not sent with my Chair hat on.

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 31 Oct 2005 16:19:51 -0800

On Oct 31, 2005, at 2:05 PM, Julian Reschke wrote:

>>>> The original question that brought up this issue was how to 
>>>> interpret the URLs inside the body of the Multi-Status if there was 
>>>> a Location
>>>
>>>
Sept 15, 2002, mail from me entitled "Issues from Interop/Interim WG 
Meeting".

"- Clients get confused if host names change; Clients expect
full/relative URLs? Dealt with in text on multistatus response"

The Location header was what the server was using to indicate the host 
name redirection in this case, which I didn't mention in this brief 
summary unfortunately.

The full details of the Interop -- e.g which client this was, and which 
server -- were never published, a decision we made in order to get 
broader participation in the Interop.

Lisa