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

[Bug 47] New: 3xx in multistatus

From: <bugzilla@soe.ucsc.edu>
Date: Sat, 27 Nov 2004 05:06:09 -0800
Message-Id: <200411271306.iARD69Bo015866@ietf.cse.ucsc.edu>
To: w3c-dist-auth@w3.org

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

           Summary: 3xx in multistatus
           Product: WebDAV-RFC 2518-bis
           Version: -06
          Platform: Other
               URL: http://lists.w3.org/Archives/Public/w3c-dist-
                    auth/2004JulSep/0154.html
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: 12.  Multi-Status Response
        AssignedTo: joe-bugzilla@cursive.net
        ReportedBy: julian.reschke@greenbytes.de
                CC: w3c-dist-auth@w3.org


The 300-303, 305 and 307 responses defined in HTTP 1.1 normally take
    a Location header to indicate where the client should make the
    request.  The Multi-Status response syntax as defined in RFC2518 did
    not allow for the Location header information to be included in an
    unambiguous way, so servers MAY choose not to use these status codes
    in Multi-Status responses. If a clients receives this status code in
    Multi-Status, the client MAY reissue the request to the individual
    resource, so that the server can issue a response with a Location
    header for each resource.

    Additionally, this specification defines a new element that servers
    MAY use in the response element to provide a location value in
    Multi-Status (see section 13.29).

I think we can improve that:

- "not to use" -- be clear what this means -- is it using a "200" status 
element instead?

- when the server chooses not to return the 3xx code, should it include 
the location element nevertheless (I think it should)



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
Received on Saturday, 27 November 2004 13:06:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:17:51 UTC