Subject: [alto] RFC2616 vs. draft-ietf-alto-protocol-08

From: Robert Varga <[email-masked]>
Date: Mon, 13 Jun 2011 20:03:02 +0200

Hi everyone,

going through the latest draft, I think we have a slight problem with
the way the draft uses Accept: header.

Let's do the following request:

   POST /costmap/filtered HTTP/1.1
   Host: custom.alto.example.com
   Content-Type: application/alto-costmapfilter+json
   Accept: application/alto-costmap+json

   {
     "cost-mode" : "INVALIDUNSUPPORTEDUNKNONW",
     "cost-type" : "routingcost",
     "pids" : {
       "srcs" : [ "PID1" ],
       "dsts" : [ "PID1", "PID2", "PID3" ]
     }
   }

Upon parsing this request, the server determines that the requested
cost-mode is completely bogus and, according to section 7.4., it needs to
send:

   HTTP/1.1 400 Bad Request
   Content-Type: application/alto-error+json
  
   {
      "code": "E_INVALID_COST_MODE",
      "reason": "Requested cost mode \"INVALIDUNSUPPORTEDUNKNONW\" is
not supported here"
   }

but it cannot do so while being strictly HTTP compliant, because
according to section 14.1 of RFC2616: "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."

Bye,
Robert

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 14 Jun 2011 14:39:23 +0800

I'm not certain that the Accept header supercedes other headers in this fashion.

Either way, to be nicer, having all requests also accept an error response solves the problem elegantly:

  Accept: application/alto-costmap+json,application/alto-error+json;q=0.5

I don't see great utility in adding text for this, but updating examples might help.

--Martin

On 2011-06-14 at 04:03:02, Robert Varga wrote:
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Richard Alimi <[email-masked]>
Date: Tue, 14 Jun 2011 21:12:35 -0700

> I don't see great utility in adding text for this, but updating examples might help.

Since RFC2616 seems pretty explicit about this, just updating the
examples sounds good to me.

Rich

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 28 Jun 2011 17:29:33 +0100

Rich, colleagues,

> examples sounds good to me.

I missed this thread the first time around but found it after looking through the diffs in the protocol draft and seeing you'd updated the Accept header of the examples.

While clients are free to include application/alto-error+json in the Accept: header of their request there is no requirement for them to do so.

In the example Robert gives below, a request containing an invalid cost-mode is a Bad Request and the appropriate HTTP response code is 400. In the case of 40X responses a server is allowed to return an entity body and there is no restriction that that entity body must match one of the media-types in the Accept: header of the corresponding request.

A 406 response means that the server could match the request to a resource (i.e. it was, in fact, a valid request) but that the media-type of the resource is different to the requested media-types specified in the Accept: header of the request.

Furthermore, 2616 states under the definition of the 406 error code that:

      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.

I don't think we need to make any changes to the protocol draft in this regard but I just wanted to make folks aware that the explicitness of 2616 with respect to 406 responses is in the context of valid requests only and then is still optional for HTTP/1.1 servers.

Ben