W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2006

[Bug 211] Inconsistencies about Destination header

From: <bugzilla@soe.ucsc.edu>
Date: Sun, 8 Jan 2006 03:03:36 -0800
Message-Id: <200601081103.k08B3ahC029815@ietf.cse.ucsc.edu>
To: w3c-dist-auth@w3.org

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

julian.reschke@greenbytes.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |
            Version|-09                         |-10



------- Additional Comments From julian.reschke@greenbytes.de  2006-01-08 03:03 -------
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-latest.html#rfc.section.9.3>:

"If the source server cannot attempt a copy to the remote server, it MUST fail
the request with a 502 (Bad Gateway) response."

This is a new MUST-level requirement (compared to RFC2518) with which I'm not
comfortable with. I do agree that most servers indeed use 502 in this case, but
a MUST level req doesn't seem right here; in particular the HTTP's definition of
502 doesn't really seem to match:

"The server, while acting as a gateway or proxy, received an invalid response
from the upstream server it accessed in attempting to fulfill the request."

...because this implies that the source server indeed has attempted to talk to
the destination server. 

Indeed, it seems to make more sense for a source server that doesn't support
this scenario to return a 4xx (client error), making clear that under no
condition the server will be able execute the request.

Propose to say:

"If the source server cannot attempt a copy to the remote server, it MUST fail
the request."

At a minimum, the MUST needs to go.




------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
You are on the CC list for the bug, or are watching someone who is.
Received on Sunday, 8 January 2006 11:03:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:12 GMT