W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

[Bug 12] Destination header "consistent"

From: <bugzilla@soe.ucsc.edu>
Date: Sat, 19 Nov 2005 01:32:49 -0800
Message-Id: <200511190932.jAJ9Wn7G020322@ietf.cse.ucsc.edu>
To: w3c-dist-auth@w3.org


julian.reschke@greenbytes.de changed:

           What    |Removed                     |Added
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |
            Version|-07                         |-08

------- Additional Comments From julian.reschke@greenbytes.de  2005-11-19 01:32 -------
The original section about the "Location" header was removed, which is good. It
didn't make any sense.

There's a new section that was silently added

Use of the Location header with the Multi-Status response is intentionally

Although this is technically, I'd prefer it not to be in. There are many things
in RFC2616 for which the spec doesn't define anything particular, and this is
not because the WG didn't want to, but because, in general, the definition in
RFC2616 should be enough. I don't recall anybody *ever* asking for this; the
recent discussion on the mailing list showed that the original trigger was an
interop meeting where there was a discussion about the "Content-Location"
header, which is a completely different thing.

The next text goes on saying:

Note that this specification does not define a way to redirect requests for
individual resources within the scope of a Multi-Status response. The server MAY
always redirect the entire request by responding with a 300 level status
response instead of a Multi-Status response.

Which means that the resolution for bug "MULTISTATUS_FOR_NON_DEPTH" from
<http://www.webdav.org/wg/rfcdev/issues.htm> (marked "inbis" over there) has
been removed, to which I object (I will open a new issue for this).

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Saturday, 19 November 2005 09:32:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:33 UTC