-
Notifications
You must be signed in to change notification settings - Fork 30.2k
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
doc: remove "is recommended" from crypto legacy API text #34697
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If your recommendation is to doc deprecate it, then why not just do so in this PR? I'd prefer that over only removing the "not recommended" text
b264d46
to
9a6ed8c
Compare
OK, I've added a second commit that applies the documentation-only deprecation to the Legacy API. /ping @nodejs/crypto (I'm leaving it as a separate commit in case there's push-back on the deprecation. Whether or not we deprecate, I think we should still clarify the wording so I want to make sure that stays even if we decide against deprecating.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
The HTTP/2 spec allows Host to be used instead of :authority in requests, and this is in fact *preferred* when converting from HTTP/1. We erroneously treated Host as a connection header, thus disallowing it in requests. The patch corrects this, aligning Node.js behaviour with the HTTP/2 spec and with nghttp2: - Treat Host as a single-value header instead of a connection header. - Don't autofill :authority if Host is present. - The compatibility API (request.authority) falls back to using Host if :authority is not present. This is semver-major because requests are no longer guaranteed to have :authority set. An explanatory note was added to the docs. Fixes: nodejs#29858 PR-URL: nodejs#34664 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Gerhard Stöbich <[email protected]> Reviewed-By: Yongsheng Zhang <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Ricky Zhou <[email protected]>
Adds support for reading from a stream where the final frame is a non-empty DATA frame with the END_STREAM flag set, instead of hanging waiting for another frame. When writing to a stream, uses a END_STREAM flag on final DATA frame instead of adding an empty DATA frame. BREAKING: http2 client now expects servers to properly support END_STREAM flag Fixes: nodejs#31309 Fixes: nodejs#33891 Refs: https://nghttp2.org/documentation/types.html#c.nghttp2_on_data_chunk_recv_callback PR-URL: nodejs#33875 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]>
Fixes: nodejs#34787 PR-URL: nodejs#34789 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: Derek Lewis <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Mary Marchini <[email protected]>
PR-URL: nodejs#34739 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: David Carlier <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
PR-URL: nodejs#34655 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: nodejs#34655 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: nodejs#34655 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: nodejs#34669 Reviewed-By: Anna Henningsen <[email protected]>
PR-URL: nodejs#34669 Reviewed-By: Anna Henningsen <[email protected]>
PR-URL: nodejs#34669 Reviewed-By: Anna Henningsen <[email protected]>
PR-URL: nodejs#34741 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Using a static label is sufficient. PR-URL: nodejs#34741 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: nodejs#34741 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: nodejs#34741 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Initial PR had it so that user code would create BlockList instances. This sets it up so that instances can be created internally by Node.js PR-URL: nodejs#34741 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: nodejs#34741 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
s/docs/doc/g Signed-off-by: Mary Marchini <[email protected]> PR-URL: nodejs#34811 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
This can currently be triggered when posting a closing FileHandle. Refs: nodejs#34746 (comment) PR-URL: nodejs#34766 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: David Carlier <[email protected]> Reviewed-By: James M Snell <[email protected]>
Update ESLint to 7.7.0 PR-URL: nodejs#34783 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Trivikram Kamat <[email protected]> Reviewed-By: James M Snell <[email protected]>
PR-URL: nodejs#34782 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Harshitha K P <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
PR-URL: nodejs#34070 Reviewed-By: Zeyu Yang <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: James M Snell <[email protected]>
As best as I can tell, ERR_V8BREAKITERATOR is unused anywhere in our code base and dependencies. Move to legacy errors. PR-URL: nodejs#34792 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
@jasnell OK to clear your objection? I think the subsequent change aligns with your suggestion? |
In test-http-destroyed-socket-write2, the assert.strictEqual() in the default case of the switch statement will always fail because it checks for a value that is already accounted for in one of the switch cases. Convert it to assert.fail(). PR-URL: nodejs#34793 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: James M Snell <[email protected]>
The text for the legacy API sends mixed signals. It's legacy, but still supported, so not deprecated, but not recommended. Let's begin to clarify this by removing "not recommended". If we want to not-recommend it, let's doc-deprecate it properly, or at least include an explanation as to why it's not recommended. PR-URL: nodejs#34697 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ujjwal Sharma <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
Documentation-only: Recommend people use the static methods on crypto.Certificate() and not the legacy API constructor. PR-URL: nodejs#34697 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ujjwal Sharma <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
Landed in aa5361c...ca5ff72 |
The text for the legacy API sends mixed signals. It's legacy, but still supported, so not deprecated, but not recommended. Let's begin to clarify this by removing "not recommended". If we want to not-recommend it, let's doc-deprecate it properly, or at least include an explanation as to why it's not recommended. PR-URL: #34697 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ujjwal Sharma <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
Documentation-only: Recommend people use the static methods on crypto.Certificate() and not the legacy API constructor. PR-URL: #34697 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ujjwal Sharma <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
The text for the legacy API sends mixed signals. It's legacy, but still supported, so not deprecated, but not recommended. Let's begin to clarify this by removing "not recommended". If we want to not-recommend it, let's doc-deprecate it properly, or at least include an explanation as to why it's not recommended. PR-URL: #34697 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ujjwal Sharma <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
Documentation-only: Recommend people use the static methods on crypto.Certificate() and not the legacy API constructor. PR-URL: #34697 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ujjwal Sharma <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
The text for the legacy API sends mixed signals. It's legacy, but still supported, so not deprecated, but not recommended. Let's begin to clarify this by removing "not recommended". If we want to not-recommend it, let's doc-deprecate it properly, or at least include an explanation as to why it's not recommended. PR-URL: #34697 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ujjwal Sharma <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
The text for the legacy API sends mixed signals. It's legacy, but still supported, so not deprecated, but not recommended. Let's begin to clarify this by removing "not recommended". If we want to not-recommend it, let's doc-deprecate it properly, or at least include an explanation as to why it's not recommended. PR-URL: #34697 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ujjwal Sharma <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
The text for the legacy API sends mixed signals. It's legacy, but still
supported, so not deprecated, but not recommended. Let's begin to
clarify this by removing "not recommended". If we want to not-recommend
it, let's doc-deprecate it properly, or at least include an explanation
as to why it's not recommended.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes