-
-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support charset in accept header #17
Comments
Hi @FredrikFolkesson thanks for the report! I'm not quite following here. Would you be able to do one of the following? (a) make a pull request with the change needed to make in the |
Hi, This "app" shows the error
|
Ah, thanks. Yes, this is working as expected and according to the RFC. In your example, the client doesn't accept |
The English version of your code is the client says: "I only accept a response in the representation of application/json; charset=utf-8" And the server knows: "I can produce a response in the representation application/json" The reason const accepts = require('accepts');
const req = {}
req.headers = {}
req.headers.accept = "application/json"
const accept = accepts({ headers: { accept: 'application/json; charset=utf-8' }});
// => application/json;charset=utf-8
console.log(accept.type(['application/json;charset=utf-8']))
const accept2 = accepts({ headers: { accept: 'application/json' }});
// => application/json;charset=utf-8
console.log(accept2.type(['application/json;charset=utf-8'])) |
@dougwilson But then the documentation is wrong? https://github.com/jshttp/accepts#types
And |
It could probably be a bug with the getting the list operation. |
Sorry to necromance, but stumbled upon this and don't know whether this has changed in a higher express version: I solved this by calling negotiator directly Node repl
This would be compliant with what I would expect from accepts, but could not find that behaviour to be working. |
Unless there is no specific support for this wanted I believe it to be a subtle issue in /index.js in the sequence around the filtering and gonna attempt an investigation. No expert on RFCs, but looking at comparable libs I think it's rather wanted to parse out the charset and seems accidental(?). In any case thanks for all the efforts |
@dougwilson obviously you are right to mention the RFC, however I think the mentioned section is a bit confusing and this one would take precedence no? https://tools.ietf.org/html/rfc7231#section-3.1.1.1 that section mentions the wanted extensibility so an aggressive filter might not appropriate(?) |
Digging deeper I am pretty sure this is unwanted. The error arises from the Negotiator interface providing a priority prop, that compares parsed mediaTypes with the header, but then also then maps only those priorities around here priorities https://github.com/jshttp/negotiator/blob/master/lib/mediaType.js#L162-L182 Originated here https://github.com/jshttp/accepts/blob/master/index.js#L105 |
Hi @eljefedelrodeodeljefe , I'm sorry you are having issue. Unfortunately I am not really following along here. If you are having the same issue as the OP (I assume so, because this is the same thread), I think what I said at #17 (comment) still stands. It may help if maybe you can take that statement I made there are make adjustments to what it should be and provide references to the RFC to support the changes you are asking for. |
Thanks for replying @dougwilson, also no follow up needed, but as an explanation: Not having a hard issue, as I workaround it anyhow and I know Fastify does too https://github.com/fastify/fastify-accepts. The original problem rather arises the caller of Reading the RFC for my taste it should allow that. But again, no strong feelings. |
A header like this
application/json; charset=utf-8
Works correctly with
accept.types()
=>[ 'application/json' ])
But
accept.type(['text', 'application/json']
oraccept.type(['text', 'json']
givesfalse
It seems to be a problem here:
https://github.com/jshttp/negotiator/blob/master/lib/mediaType.js#L141
Since we then compare the keys and our accepted type
application/json
does not have the charset key.The text was updated successfully, but these errors were encountered: