- From: <bugzilla@soe.ucsc.edu>
- Date: Sun, 4 Dec 2005 03:17:54 -0800
- 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 UTC