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

[Bug 47] 3xx in multistatus

From: <bugzilla@soe.ucsc.edu>
Date: Sun, 4 Dec 2005 03:17:54 -0800
Message-Id: <200512041117.jB4BHsUl011042@ietf.cse.ucsc.edu>
To: w3c-dist-auth@w3.org

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

julian.reschke@greenbytes.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |



------- Additional Comments From julian.reschke@greenbytes.de  2005-12-04 03:17 -------
Thanks for the changes in the 2005-12-03 draft, but there are still some
problems, the changes below attempt to remove them.

OLD:

 12.1  Response headers
 
    Use of the Location header with the Multi-Status response is
    intentionally undefined.  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.

NEW:

(remove that section)

Section 12., para. 12:
OLD:

    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 the body of Multi-Status responses.  If a client 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.

NEW:

    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.  In [RFC2518], the multistatus response format did not
    define a container for the Location header information, so servers
    MAY choose not to use these status codes in the body of Multi-Status
    responses.  In this case, a client receives this status code in
    Multi-Status, it may reissue the request to the individual resource,
    so that the server can issue a response with a Location header for
    that resource.


Section 12., para. 13:
OLD:

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

NEW:

    Additionally, this specification defines a new element that servers
    may use in the response element to provide a location value inside a
    multistatus response (see Section 13.9).

(we're not making a nomative statement here, so MAY is wrong; also fixes the
reference)

Section 13., para. 41:
OLD:

    Purpose:  In normal responses (not Multi-Status), some status codes
       go along with a Location header.  When these status codes are used
       in a Multi-Status response, this element is used instead.

NEW:

    Purpose:  HTTP defines the 'Location' response header (see [RFC2616],
       Section 14.30) for use with some HTTP status codes (such as 201
       and the 300 series codes).  When these status codes are used
       inside a 'multistatus' response body, this element can be used to
       provide the accompanying 'Location' header.

(among other things, include a ref to the right RFC2616 section)

Section 13., para. 42:
OLD:

    Description:  Contains a single href element with the same URL that
       would be used in a Location header.

NEW:

    Description:  Contains a single href element with the same value that
       would be used in a Location header.

(Location is not restricted to be a URL)



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
Received on Sunday, 4 December 2005 11:18:00 GMT

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