Richard, On 21 Mar 2013, at 09:28, Richard Alimi wrote:
> Thanks for the fast reply! A couple of things inline. Not so fast this time I'm afraid :-( > On Thu, Mar 21, 2013 at 1:46 AM, Ben Niven-Jenkins <[email protected]> > wrote: > 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. > > RA>Ah - thanks for pointing out that additional section. So based on this, > then would you suggest guidance for ALTO Servers in our protocol spec that > they should return an ALTO Error response in preference to a 406? We were > hoping to avoid these types of cases where we guide on how to use HTTP. I don't think you need to add any guidance to the spec. At the end of the day an error has occurred and it is unlikely the ALTO client can recover automatically from it so it is unlikely the ALTO client is going to use the ALTO server's behaviour to decide what to do next. So I'd just leave it to ALTO server implementations to decide what they want to do in this case. > > > 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. > > RA> Well, the "no Accept header" case is easier - rfc2616 indicates that that > means the client accepts everything :) > > RA> Leaving the ALTO Protocol spec as-is is fine with me, modulo my question > above about what to do with the server-side. > > > > 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. > > RA> Okay. Do you think its worth giving any guidance at all in the ALTO > protocol spec? I don't think you need guidance in the spec over and above what you already have. Ben > On one hand, we don't want to duplicate contents of rfc2616, but on the > other, rfc2616 seems to require implementers to independently come up with > something they feel is "reasonable" for these kinds of cases based on their > interpretation of the spec. > > Thanks, > Rich > > > 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
