Repository navigation
Conversation
This was written based on RFC 9110, but right now it doesn't work - jshttp/accepts#82. Separate commit to make it easier to revert/drop.
Since first Express 3.0 alpha this function returns the accepted type (or false). true was returned in versions of Express prior to 3.x. The behaviour change occurred on 2012-03-24 (in multiple commits), but, because of how these tests were written, it did not affect tests even when the return type changed. expressjs@365a98d expressjs@86a9e08 expressjs@298899d
…not present The new acceptsEncodings test will fail. I consider this to be a bug in jshttp/accepts. jshttp/accepts#83 (comment)
That's the form `req.acceptsLanguages` was already using.
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
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.
What pushed me to look into this (skip this if you value your time)
Background
#6088 changed the wording of
req.acceptsCharsets()docs and introduced a mistake which went unnoticed until #7451, where it was reported as a bug in code. Interestingly, 9 days later #6936 fixed the same mistake in docs forreq.accepts()and in #6936 (comment) @bjohansebas pointed out that Express had removed support for comma delimited string before 4.0 release. Historically it looks more or less like this:jshhtp/accepts, which does not accept a single comma delimited string, but leaves it in the docs.req.accepts()toreq.acceptsCharsets(). The PR appears to be at least AI-assisted, if not completely AI-generated, but this does not explain why nobody noticed this during review. It is possible that the text wasn't based onreq.accepts(), but the LLM just wrote false information in docs and PR description - it sounds as if the author completely rewrote the method to extend the functionality, while in reality the changes to code were just cosmetic.req.accepts()docs.req.acceptsCharsets()docs become a part of Express.req.accepts()docs.Conclusions? Maybe I should check PRs after they're merged if I've ignored them before...
TL;DR
req.acceptsCharsetsJSDoc comment claimed support for something that has not been supported since Express 4 and an LLM (user?) tried to "fix" it in code.Description
req.accepts,req.acceptsEncodings,req.acceptsCharsets,req.acceptsLanguagesare almost identical so I tried to:falseor the string),falseor the best/preferred),falseor the best/preferred),acceptsLanguagesimplementation using spread operator #6137),Problems and things to discuss
negotiator/accepts/expresswhenAccept-Encodingis missing does not match my interpretation of the standard - NoAccept-Encodingdefaults to only'identity'jshttp/accepts#82deletes a header, because of a problem withsuperagent- [fix] Cannot unsetAccept-Encodingforwardemail/superagent#1860req.acceptsCharsetsnow contains a note that theAccept-Charsetheader is deprecated - is it something that should be included in the docs?If this is merged, the docs on the website should be updated too. On the website only
req.acceptsLanguages()hasString[]in return types.TODO:
@param {...string} nameworks with TS (...string[]that I use now I think is incorrect JSDoc)Closes #7470