Repository navigation
fix(search-api-graphql): send Vary and Content-Language for Accept-Language - #917
Merged
Merged
Conversation
…nguage - Append Vary: Accept-Language to every GraphQL response, so a shared cache keys on the header that output order and search locale follow - Collect the languages of served LanguageStrings on an optional SearchContext.servedLanguages set; report them in Content-Language - Leave malformed tags out of the header and fold case-only duplicates, since tags come from indexed data
- Canonicalise served tags with Intl.getCanonicalLocales, which rejects malformed tags and folds case, instead of a hand-written pattern - Re-anchor the branch threshold for the removed branches
- Use Intl only to validate tags, so the header names a language the way LanguageString.language serves it (iw, not its alias he) - Skip untagged values in any case (UND), not only lowercase und
…guage - Record each LanguageString list's [0] language, the value a client displays, rather than every language behind it - Bound the header by what was requested instead of by how many languages the data holds
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The GraphQL handler’s response depends on
Accept-Language, but the handler sent neitherVarynorContent-Language. So a shared cache could serve one requester’s language order to the next.Vary: Accept-Languageis appended to every response from the endpoint (appended, so CORS’sVary: Originsurvives).Content-Languagelists the displayed language –[0].language– of every localized value in the response, in the order first served. A mixed-language page lists each (en, nlwhen one item has no English value), as RFC 9110 §8.5 allows. The languages behind[0]are left out, so the header grows with what was requested, not with how many languages the data holds; ADR 0004 already calls[0].languagethe per-fieldContent-Language. A response without tagged values sends none.LanguageStringresolvers record their displayed language on a new optionalSearchContext.servedLanguagesset. The handler creates the set per request, passes it in as Yoga server context, and reads it once execution finishes. I chose this over walking the result JSON, which can’t see through field aliases.Intl.getCanonicalLocalesand drops a malformed one (it would make an invalid header and fail the request). Valid tags keep the spelling the body serves them in, so the header andLanguageString.languagename the same languages (iwstaysiw). Case-only duplicates are folded, and untagged values are skipped whatever their case (UND).Negotiation still never fails: the
undfallback stays.Fix #800