{"action":"opened","issue":{"url":"https://api.github.com/repos/jshttp/accepts/issues/16","repository_url":"https://api.github.com/repos/jshttp/accepts","labels_url":"https://api.github.com/repos/jshttp/accepts/issues/16/labels{/name}","comments_url":"https://api.github.com/repos/jshttp/accepts/issues/16/comments","events_url":"https://api.github.com/repos/jshttp/accepts/issues/16/events","html_url":"https://github.com/jshttp/accepts/issues/16","id":319899544,"number":16,"title":"Implementing \"406: not acceptable\"","user":{"login":"pietercolpaert","id":347073,"avatar_url":"https://avatars1.githubusercontent.com/u/347073?v=4","gravatar_id":"","url":"https://api.github.com/users/pietercolpaert","html_url":"https://github.com/pietercolpaert","followers_url":"https://api.github.com/users/pietercolpaert/followers","following_url":"https://api.github.com/users/pietercolpaert/following{/other_user}","gists_url":"https://api.github.com/users/pietercolpaert/gists{/gist_id}","starred_url":"https://api.github.com/users/pietercolpaert/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pietercolpaert/subscriptions","organizations_url":"https://api.github.com/users/pietercolpaert/orgs","repos_url":"https://api.github.com/users/pietercolpaert/repos","events_url":"https://api.github.com/users/pietercolpaert/events{/privacy}","received_events_url":"https://api.github.com/users/pietercolpaert/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-05-03T12:28:17Z","updated_at":"2018-05-03T12:28:17Z","closed_at":null,"author_association":"NONE","body":"## Context\r\n\r\nIn order to write a spec compliant content negotiation on the server, we also need to handle a request with e.g., the extreme `accept: */*;q=0`, which should return a `406 not acceptable`.\r\n\r\nUse cases are for example: a client that can only parse 1 serialization to do something like `accept: application/json;q=1,*/*;q=0`. If the server cannot provide an answer, the client will get the convenient 406.\r\n\r\n## Problem\r\n\r\nIn the accepts package, the server asks the client whether it accepts a certain list of values as follows (as copied from the README.md):\r\n``` // the order of this list is significant; should be server preferred order\r\n  switch (accept.type(['json', 'html'])) {\r\n    case 'json':\r\n      ...\r\n      break\r\n   case default:\r\n      ...\r\n      break\r\n  }\r\n```\r\nThe list `['json','html']` is the server-side list of preferences, yet the client also may have its *preferences*. It’s not because a client does not have `application/json` in its client-side list, that it cannot parse JSON. So, if the client is asking only for `application/xml`, but the server cannot offer that, the functionality should be that `application/json` is returned, as this is the preference from the server. Right now, the accepts library would return null, and leave the spec compliant implementation up to the user of the package. Yet probably, that user is not going to go through the pain of parsing the accept header all over again.\r\n\r\nAn extra note: it may be that the client cannot parse json at all, and wants to indicate that it can `only` parse XML.\r\n\r\n## Suggested solution\r\n\r\nInstead of `accept.type(['a','b','c'])` is false or the format that is mentioned in the accept header of the request, I would only return false (and thus let the developer know it should return a 406) when the client indicated it does not accept any of the server-side representations. This function must return the first representation that is not `not acceptable` by the client.\r\n\r\nWhen this is implemented, this would be a breaking change and would require a new major version number of this package.\r\n\r\n## RFC compliant explanation\r\n\r\nhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation"}}
{"actor":{"display_login":"pietercolpaert"}}