I could have sworn that some version of the protocol said something like,
"A server may assume that a client will accept an alto-error+json response
even if that's not in the Accept header."
According to my notes, in July 2012, I revised my ALTO server to do that.
I don't think I came up with that idea on my own. Perhaps it was a result
of the interop discussions.
In any case, why not just add language like that to the protocol spec?
- Wendy Roome
>Date: Thu, 21 Mar 2013 08:46:30 +0000
>From: Ben Niven-Jenkins <[email protected]>
>
>Hi Rich,
>
>On 21 Mar 2013, at 07:30, Richard Alimi wrote:
>
>>Hi Ben,
>>We are revisiting this again as we're making the final push on the
>>document. Reading RFC2616, I see the text that you've quoted for the
>>Accept-Encoding header, but not for the Accept header. In
>>particular,http://tools.ietf.org/html/rfc2616#section-14.1 simply states:
>> If no Accept header field is present, then it is assumed that the
>> client accepts all media types. If an Accept header field is present,
>> and if the server cannot send a response which is acceptable
>> according to the combined Accept field value, then the server SHOULD
>> send a 406 (not acceptable) response.
>
>But section 10.4.7 says
> Note: HTTP/1.1 servers are allowed to return responses which are
> not acceptable according to the accept headers sent in the
> request. In some cases, this may even be preferable to sending a
> 406 response. User agents are encouraged to inspect the headers of
> an incoming response to determine if it is acceptable.
>
>>Given this and the fact that draft-ietf-httpbis-p2-semantics is not yet
>>published, we are left in the intermediate state. According to what's
>>published now, it looks like an ALTO Client should add
>>application/alto-error+json in its set of accepted content types. Is
>>that an accurate understanding?
>
>There aren't any hard rules here AFAIK. I guess strictly speaking if the
>client has included an Accept header and it supports
>application/alto-error+json, it should add it to the Accept header.
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
