willfarrell
commented
2 years ago Thanks for requesting. I do think a default language is important and should be included within the core middleware. Since v3 is still waiting for AWS (but expected in the next week), we should apply this change before it goes out. I can add this is pretty easily. Which do you prefer?
defaultLanguage: 'en'
or
defaultLanguage: true // where it uses the first item in the availableLanguages array
I prefer the later one because it doesn't need to check that the defaultLanguage value is within the availableLanguages array.
jcmartincapitan
Is your feature request related to a problem? Please describe. When we use the middleware httpContentNegotiation, in our case for get the preferredLanguage for a user, we can specify the valid values but in case to not receive this header or to receive an invalid value, we cannot specify a default value and we need to use other methods to set this default language value.
Describe the solution you'd like I think that include new optional properties that let us include a default value in case that the header is undefined or does not match with the available${types} could be a good solution.
Describe alternatives you've considered The other solutions are include this default value outside the middleware. In our case we think in 2 different solutions, or include a second middleware that populate the default value in case that the preferedLanguage is undefined or have the language property in the functions with a default language value. I don't see any of this 2 approaches better than add the default value in the httpContentNegotiation middleware.
Additional context In this scenarion we need to think how the FailOnMissmatch will work. If FailOnMissmatch is true but you specify the default value, this means that will never fail because you always will have a default value? Or this means that only will fail when the header is not null but the given value does not match with the one in the available values?