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:


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


Lisa


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


<excerpt><excerpt>

</excerpt>Lisa writes:


<excerpt>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. 

</excerpt>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


<excerpt>

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 


On Oct 27, 2005, at 8:17 PM, Geoffrey M Clemm wrote:



<excerpt>

<smaller>+1</smaller> 


<fixed><color><param>0000,0000,EEED</param><x-tad-smaller>w3c-dist-auth-request@w3.org</x-tad-smaller></color><x-tad-smaller>
wrote on 10/27/2005 07:50:06 PM:</x-tad-smaller></fixed>


<fixed><x-tad-smaller> > </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > Julian writes:</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > Back to this issue:</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > 1) I'm not aware of any interop problems.</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > 2) I'm not aware of anybody having asked
about this.</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > 3) I don't see any benefit in RFC2518bis
making statements about</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > this, even if we *did* agree on what to say</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > I have just read through this entire thread,
and I agree with his</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > statement above, and the conclusion Julian
reached in:</x-tad-smaller></fixed>

<fixed><x-tad-smaller> >
</x-tad-smaller><color><param>0000,0000,EEED</param><x-tad-smaller>http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0294.html</x-tad-smaller></color></fixed>

<fixed><x-tad-smaller> > </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > Specifically:</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > * I don't think there is a compelling need to
disallow Location and 207</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > * I don't think we need any special mechanism
for handling 3xx within</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > a PROPFIND</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > * I think it's fine if a client needs to
retry a PROPFIND request if</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > it receives a 3xx response</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > I feel a slight desire to add a 3xx response
to one of the PROPFIND</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > 207 response examples in the text, but could
live without it.</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > Unless others chime in, I think we're seeing
rough consensus for</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > removing the current 8.1.3, whose text is
described in Bug 12 within</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > Bugzilla:</x-tad-smaller></fixed>

<fixed><x-tad-smaller> >
</x-tad-smaller><color><param>0000,0000,EEED</param><x-tad-smaller>http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12</x-tad-smaller></color></fixed>

<fixed><x-tad-smaller> > </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > - Jim</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > </x-tad-smaller></fixed>

</excerpt></excerpt></excerpt></excerpt>