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.
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
Thanks, Sergey
>
> Best regards, Julian
>
>> Are implementations expected to provide a body, in addition to HTTP
>> Allow header ?
>>
>> Thanks, Sergey
>>
>> [1]
>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-4.3.7
>>
>>
>>
>