W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: #332, was: Redirect fallback requirements

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 26 Jan 2012 17:47:16 +0100
Message-ID: <4F218394.7060701@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 2012-01-26 01:34, Mark Nottingham wrote:
> ...

> On 26/01/2012, at 6:30 AM, Julian Reschke wrote:
>
>> On 2012-01-25 01:07, Julian Reschke wrote:
>>> ...
>>> The question remains whether we should relax more of the SHOULD-level
>>> requirements on response payloads. At least some of them seem fishy (not
>>> necessarily the 3xx ones). Will send separate mail later this week.
>>> ...
>>
>> Here we go; excerpts from P2 Section 7:
>>
>> 7.2.2.  201 Created
>>
>>    The request has been fulfilled and has resulted in a new resource
>>    being created.  The newly created resource can be referenced by the
>>    URI(s) returned in the payload of the response, with the most
>>    specific URI for the resource given by a Location header field.  The
>>    response SHOULD include a payload containing a list of resource
>>    characteristics and location(s) from which the user or user agent can
>>    choose the one most appropriate.  ...
>>
>> This seems fishy. In particular it makes little sense for PUT->2
>
> +1. Downgrade to prose?
>
>>
>>    ... The payload format is specified by
>>    the media type given in the Content-Type header field.
>>
>> Some status codes descriptions state this, some do not. It is always true, however. Maybe just say this once at the beginning of Section 7?
>
> +1
> ...

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1515>

   "For most status codes the response can carry a payload, in which case
    a Content-Type header field indicates the payload's media type
    (Section 6.8 of [Part3])."

Hopefully that's precise enough...

Best regards, Julian
Received on Thursday, 26 January 2012 16:47:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:53 GMT