i18next / i18next-express-middleware

[deprecated] can be replaced with i18next-http-middleware
https://github.com/i18next/i18next-http-middleware
MIT License
207 stars 55 forks source link

Invalid value "undefined" for header "Content-Language" with 1.9.0 #200

Closed zsgalusz closed 4 years ago

zsgalusz commented 4 years ago

Since the new version released today, all our apps started failing with this error:

TypeError [ERR_HTTP_INVALID_HEADER_VALUE]: Invalid value "undefined" for header "Content-Language"
    at ServerResponse.setHeader (_http_outgoing.js:488:3)
    at i18nextMiddleware (project/node_modules/i18next-express-middleware/lib/index.js:68:11)

Pinning the i18next-express-middleware version back to 1.8.2 fixes the errors. We are using a fairly vanilla express setup, very similar to the "wire up i18next to request object" example given in the readme. We do not use the language detection features of the middleware.

jamuhl commented 4 years ago

@isaachinman any idea?

isaachinman commented 4 years ago

I can take a look in about an hour, but it looks like http is doing some validation that Express wasn't.

isaachinman commented 4 years ago

@zsgalusz Can you confirm if your app is casting undefined to a string?

jamuhl commented 4 years ago

wondering a little how lng can be undefined?

situation a) https://github.com/i18next/i18next-express-middleware/blob/master/src/index.js#L45 --> your app only works on fallbackLng (makes no sense)

situation b) https://github.com/i18next/i18next-express-middleware/blob/master/src/index.js#L29 --> there was a language change call from within the request to undefined (makes also no sense)

jamuhl commented 4 years ago

ok guess I see, we avoid problems by enforcing the fallback language: https://github.com/i18next/i18next-express-middleware/blob/master/src/index.js#L50 so language can be undefined - but neither using a detector nor setting that on req.lng is rather odd`?!?

@zsgalusz why you're using this without translating? not setting any language for the request?

jamuhl commented 4 years ago

@zsgalusz could you retry with i18next-express-middleware@1.9.1 (added a check for lng is set)

but this only avoids the error - I still believe something's wrong in your setup

isaachinman commented 4 years ago

@jamuhl If the user's app is casting undefined to a string, eg "undefined", then this will actually pass the truthy check you've introduced with v1.9.1, as would any positive number, etc. Is it possible to check if lng belongs to an array of possible languages?

jamuhl commented 4 years ago

@isaachinman I guess setting "undefined" is possible -> I believe it is really setting undefined which is not allowed -> I believe the error message output casts it to string

isaachinman commented 4 years ago

Okay, wasn't sure! That's fine then. This is a weird one either way.

zsgalusz commented 4 years ago

1.9.1 does fix the error, thank you for the fast response!

Our setup in detail: We are running on a node/express platform that does its own language detection, so we do not need the built-in ability of the middleware. We use the middleware like this:

i18next
  .use(initReactI18next)
  .use(i18nextFSBackend)
  .init({
    keySeparator: '$',
    fallbackLng: 'en',
    interpolation: {
      escapeValue: false,
    },
    backend: {
      loadPath: path.resolve(
        'statics/assets/locale/all/messages_{{lng}}.json'
      ),
    },
  })

app.use(i18nMiddleware.handle(i18next));

// later in request handler:
  let language = _get(req, 'aspects.web-context.language', 'en');
  req.i18n.changeLanguage(language);

So yes I suppose until we receive the languages from the platform in the handler, the language indeed is not set.

jamuhl commented 4 years ago

@zsgalusz thank you for making your setup more clear -> looks valid - so glad the provided fix works for you