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. 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? The followup question to that: if the ALTO Client should add application/alto-error+json in its list of accepted content types, do we need to document this in the ALTO Protocol draft? When discussing this amongst the editors, our general belief was that if the HTTP spec is not clear on what should be done, then it's a problem with the HTTP spec and it should be addressed there and not in the ALTO Protocol spec. If we do need to add some text in the ALTO Protocol draft, then perhaps it should be separated into a discussion section. A related question is whether the client needs to include application/alto-directory+json in its list of accepted content types if the ALTO Server *could* potentially reply with an 300 "Multiple Choices" formatted as a resource directory. My reading of RFC2616 and draft-ietf-httpbis-p2-semantics doesn't turn up any guidance on this, but my guess is that the ALTO Server could reply with a resource directory even if the client hasn't included it in the Accept header. The followup question to this: Do we need to document anything in the ALTO Protocol draft about this? The editors' opinion here is similar as above -- this sounds like something that should be documented in an HTTP spec and not the ALTO Protocol draft. Thanks, Rich On Wed, Nov 7, 2012 at 12:06 PM, Ben Niven-Jenkins <[email protected]>wrote: > Colleagues, > > During the ALTO WG session today, a question was raised against the ALTO > protocol spec about what should the behaviour be when an error occurs but > the client included an Accept: header in its request but > application/alto-error+json was not included in the Accept header. > > RFC2616 states: > If an Accept-Encoding field is present in a request, and if the > server cannot send a response which is acceptable according to the > Accept-Encoding header, then the server SHOULD send an error response > with the 406 (Not Acceptable) status code. > > However, draft-ietf-httpbis-p2-semantics (which is currently in WG LC and > will obsolete RFC2616 when published) states: > If an Accept header field is > present in a request and none of the available representations for > the response have a media type that is listed as acceptable, the > origin server MAY either honor the Accept header field by sending a > 406 (Not Acceptable) response or disregard the Accept header field by > treating the response as if it is not subject to content negotiation. > > Which confirms what I said at the mic that in the case being considered > the ALTO server is allowed to return a response with a Content-Type of > application/alto-error+json if an ALTO error occurs and the client has > included an Accept header in its request but not included > application/alto-error+json in the Accept header. > > Ben > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
