-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overzealous link header validation in writeEarlyHints
#46453
Comments
This is just a bug and no one caught it. Can you take a look @anonrig @Uzlopak? You both discussed this problem in: https://github.com/nodejs/node/pull/44820/files#r983969846. |
Removes the requirement that every call to writeEarlyHints include a `link` header. While the `link` header is clearly the most common usage of `103 Early Hints`, I could find no requirement to include a `link` header as part of [RFC8297](https://www.rfc-editor.org/rfc/rfc8297.html). Additionally this removes the existing incorrect validation of the Link header format in favor of only validating that it is a valid header value. While the validation could be updated to better match [RFC8288 Section 3](https://www.rfc-editor.org/rfc/rfc8288.html#section-3), it appears it would be the only place in the node.js code base where we proactively validate header values beyond verifying they are valid at the HTTP protocol layer. Fixes: nodejs#46453
Removes the requirement that every call to writeEarlyHints include a `link` header. While the `link` header is clearly the most common usage of `103 Early Hints`, I could find no requirement to include a `link` header as part of [RFC8297](https://www.rfc-editor.org/rfc/rfc8297.html). Additionally this removes the existing incorrect validation of the Link header format in favor of only validating that it is a valid header value. While the validation could be updated to better match [RFC8288 Section 3](https://www.rfc-editor.org/rfc/rfc8288.html#section-3), it appears it would be the only place in the node.js code base where we proactively validate header values beyond verifying they are valid at the HTTP protocol layer. Fixes: nodejs#46453
I really doesn't know why |
Updated regex for "Link" header validation to better match the specification in RFC 8288 section 3. Does not check for valid URI format but handles the rest of the header more permissively than before. Alternative to another outstanding PR that disables validation entirely. Fixes: nodejs#46453 Refs: https://www.rfc-editor.org/rfc/rfc8288.html#section-3 Refs: nodejs#46464
Updated regex for "Link" header validation to better match the specification in RFC 8288 section 3. Does not check for valid URI format but handles the rest of the header more permissively than before. Alternative to another outstanding PR that disables validation entirely. Fixes: #46453 Refs: https://www.rfc-editor.org/rfc/rfc8288.html#section-3 Refs: #46464 PR-URL: #46466 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Updated regex for "Link" header validation to better match the specification in RFC 8288 section 3. Does not check for valid URI format but handles the rest of the header more permissively than before. Alternative to another outstanding PR that disables validation entirely. Fixes: #46453 Refs: https://www.rfc-editor.org/rfc/rfc8288.html#section-3 Refs: #46464 PR-URL: #46466 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Updated regex for "Link" header validation to better match the specification in RFC 8288 section 3. Does not check for valid URI format but handles the rest of the header more permissively than before. Alternative to another outstanding PR that disables validation entirely. Fixes: #46453 Refs: https://www.rfc-editor.org/rfc/rfc8288.html#section-3 Refs: #46464 PR-URL: #46466 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Can this also be fixed on Node 18? |
@nithin-murali-arch Isn't this fixed in 18.16.0? #46466 has been backported there. |
Version
v19.5.0
Platform
Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000 arm64
Subsystem
http
What steps will reproduce the bug?
How often does it reproduce? Is there a required condition?
No response
What is the expected behavior?
No response
What do you see instead?
Additional information
This appears to be an overzelous validation that requires all link parameters to be followed by an
=
.Per the ABNF in RFC8288 https://www.rfc-editor.org/rfc/rfc8288.html#section-3 the
=
is optional along with the parameter value.Additionally it seems that the validation restricts parameters to a preset list of those headers currently defined by the HTML spec. This seems in conflict with RFC8288 which doesn't appear to place any restrictions on parameters, which seems more relevant that the parameters that happen to be specified in the current HTML specification.
The text was updated successfully, but these errors were encountered: