On 2013-05-16 18:31, Sergey Beryozkin wrote:
> Hi
> On 16/05/13 17:23, Julian Reschke wrote:
>> On 2013-05-16 17:58, Sergey Beryozkin wrote:
>>> Hi
>>>
>>> According to [1], response to OPTIONS 'SHOULD' also provide a body
>>> (albeit) in the unspecified format, as opposed to setting a well-known
>>> HTTP Allow header.
>>
>> As far as I can tell, it does not say that.
>
> This is the text, with '*' delimiters added by me :
>
> "*The response payload*, if any, might also describe the communication
> options in a machine or human-readable representation. A standard
> format for such a representation is not defined by this
> specification, but might be defined by future extensions to HTTP. A
> server MUST generate a Content-Length field with a value of "0" *if no
> payload body* is to be sent in the response."
>
> So at least there is some indication that it is an option.
Yes, it's optional. That's not a SHOULD.
> A colleague of mine also pointed to the older text
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html) where it is said
> slightly differently.
>
> FYI, I'm not advocating for the implementations to set the response
> body. We are seeing some TCK test failures where the body is checked,
> hence I'm asking. I honestly do not mind whether the body is also
> included or not :-), but the current HTTPBis text with its 'might'
> action really tells me that we rather not worry about creating an
> OPTIONS response body
Indeed, you don't need to.
Best regards, Julian