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. But the HTTP specs do allow responses other than 406 and I think I'd argue in this case it is more preferable to return the (presumably more descriptive) ALTO error in the hope the client can process it than be picky about returning a 406 without any ALTO error response. > 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. I think the HTTP spec leaves it open a bit on purpose to let servers choose a "least worst" option based on their specific application. I'd be tempted to leave things as is rather than overspecify client behaviour and possibly give some advice to server implementors that suggested returning the most descriptive response. Servers will have to handle clients making requests with no Accept header. > 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. Again I wouldn't get too hung up on it. The way I interpret the Accept header is a way for the client to signal "Given a choice I'd prefer foo over bar", sometimes it may mean "I only support foo" but in those cases if a server doesn't have a foo representation of the resource, returning bar does no harm. So where the contents of the Accept header affect the server behaviour it is useful to document that in the spec. In other cases where the server may return a different content-type entirely under some circumstances I wouldn't try and articulate all the possibilities. Ben > > 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
