Comments (8)
Can you define in what way it's not supported? As far as I know, we support it just fine. Can you show what code you tried to write, etc.?
from negotiator.
It is also very important to note that if you are looking at the charset in the Accept
header, you're kind of falling outside of the HTTP spec; you should be negotiating charset using the Accept-Charset
header instead.
from negotiator.
Hi Doug, thanks for the response. Sorry, I should have explained more or written a test - it's quite possible I've misunderstood something!
Given my request containing Accept: application/json;charset=iso-8859-1
, the following code wired in as a Hapi onPreHandler...
var negotiator = new Negotiator(request);
var charset = negotiator.charsets(['utf-8']);
console.log(charset);
produces utf-8
for negotiator 0.5.3.
Thanks for the tip on specs - you're quite right, it may be something that should be optional in your lib rather than mandatory (if supported at all)?
from negotiator.
Ah, I see your misunderstading now--.charset
and related methods are only for the HTTP Accept-Charset
header (see https://github.com/jshttp/negotiator#accept-charset-negotiation) -- they have nothing to do with the Accept
header, which is media type negotiation (using the .mediaType
methods).
from negotiator.
Whether or not the charset parameter in the accept request header is valid per the specs seems to be a bit open to interpretation, as per http://stackoverflow.com/questions/7055849/accept-and-accept-charset-which-is-superior - it's certainly not forbidden, section 3.7 of http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html says that accept and content type share the same definition of media type including parameters, and http://tools.ietf.org/html/rfc2046#section-4.1.2 states that the charset parameter is valid against the content-type media type!
I can understand why you might choose not to support it - would you consider PRs to introduce it maybe as an optional capability? Not saying that I'll have time to do that but in case I do!
Appreciate your time here btw.
from negotiator.
I'm not saying you cannot do it, but you just have to use the .mediaType
methods to get at the Accept
header; I would not accept modifying the .charset
methods in any way to pull from there, especially because the parameters on media types are defined by them, so not all media types even allow a charset
parameter, and even if they do, they can define it in any way (all RFC references need to be to 7230 or higher for HTTP/1.1--not RFC 2616, which is deprecated and obsoleted). Also, remember that the Content-Type
header is very different from the Accept
header, though parameters are of course acceptable in both :)
What is the specific reason you cannot use the Accept-Charset
header, anyway?
from negotiator.
A good example of why .charset
methods cannot look into the Accept
header is because if you have the header Accept: application/json; charset=UTF-8, test/html; charset=iso-8859-1
, you cannot possibly know which charset the client actually wants without first doing a media type negotiation, which is what the .mediaType
methods are for.
from negotiator.
I didn't realise those RFCs were deprecated. Thanks for clearing that up!
from negotiator.
Related Issues (20)
- Fails to parse quoted parameters HOT 10
- Parameter names should be case insensitive HOT 4
- Parameter value case-sensitivity is media-type specific HOT 5
- `Accept: *` results in no media types. HOT 6
- language function does not return expected language HOT 1
- Negotiator behavior on duplicate accept content-types HOT 1
- es6 support HOT 2
- Caching the availableMediaTypes HOT 1
- Functionnal API HOT 2
- Accept-Language comparing standard currently differs between `getLanguagePriority` and `compareSpecs` HOT 5
- [Bug] parseCharset(str, i) changes value of i HOT 4
- [Question] More preferredCharset() stuff HOT 2
- [Question] parseMediaType(), and parameters after q-value HOT 4
- Ship version 1 and adopt semver? HOT 9
- 0.6.3 Release HOT 8
- Inconsistent mediaType/s handling HOT 1
- Returning */* no matter what I set as header. HOT 4
- language function does not return the expected language in nextjs middleware HOT 3
- Language negotiator returns first item of availableLanguages array no matter what HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from negotiator.