Subject: [alto] ALTO error responses & HTTP's Accept header

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 7 Nov 2012 20:06:35 +0000

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