Handle q parameter in content negotation

[mfenner]

We currently are not correctly handling Accept headers with multiple content types and the q parameter.

[mpaluch]

Content negotiation does not seem to work with a single Accept value either. It returns the incorrect HTTP response code and content type. The response code should be 406 according to DOI Content Negotiation documentation.

curl -IL -H "Accept:application/vnd.crossref.unixref+xml" https://data.datacite.org/10.4224%2F23002529

HTTP/1.1 200 OK
Accept: application/vnd.crossref.unixref+xml
Access-Control-Allow-Headers: Content-Type,Accept,Accept-Encoding,Origin,User-Agent,Cache-Control,Keep-Alive
Access-Control-Allow-Methods: GET, POST, PATCH, PUT, DELETE, OPTIONS
Access-Control-Allow-Origin: *
Cache-Control: private
Content-Disposition: attachment; filename=_10.4224_23002529.xml
Content-Transfer-Encoding: binary
Content-Type: application/vnd.crossref.unixref+xml
Date: Fri, 01 Dec 2017 21:28:19 GMT
ETag: W/"36a9e7f1c95b82ffb99743e0c5c4ce95"
Server: openresty/1.11.2.2
Status: 200 OK
Vary: Accept-Encoding
X-Powered-By: Phusion Passenger 5.1.12
X-Request-Id: 8fb049de-668b-4dec-8653-62bbdabc0dc0
X-Runtime: 2.878999
Connection: keep-alive

[mfenner]

Marcin, we have changed in April 2017 how the DataCite content negotiation handles unknown content types: https://blog.datacite.org/content-negotiation-update/. Instead of a 406 error we redirect to the URL registered in the handle system. The other DOI registration agencies are not (yet) doing this, that is why the documentation you point to hasn't been updated.

application/vnd.crossref.unixref+xml is a special case, as we support it as input, but not output. This allows us to serve this content type with Crossref DOIs:

curl -LH "Accept:application/vnd.crossref.unixref+xml" https://data.datacite.org/10.1371/journal.pmed.0020024

Going forward I hope to be able to serve DataCite metadata as Crossref XML, and to align with Crossref regarding the 406 status.