-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
http: headers(Distinct), trailers(Distinct) setters to be no-op #45176
http: headers(Distinct), trailers(Distinct) setters to be no-op #45176
Conversation
For reviewers: I believe the intention of this test is to add coverage for line 145 at https://coverage.nodejs.org/coverage-fdadea8f6e42cea4/lib/_http_incoming.js.html#L145. @nodejs/testing @nodejs/http |
While the test LGTM, I now wonder if we want that property to be set by the user or just used by us internally. |
agreed @ShogunPanda. Internally there wasn't any usage of the setter and I can/t think of a good reason why users might have to set it explicitly. |
Ideally, would an attempt to set it be a no-op? Throw an error? Be undefined behavior? Something else? |
@sonimadhuri I think the thing to do for now might be to change the setter behavior to be a no-op and then update this test to check that the result doesn't change when something is assigned to it. Would you be willing to make that change? If anyone wants to make the case that an error or warning should occur, that can always be added in later pull requests by anyone who wants to make it happen. (I like the idea of emitting a warning personally, but I'm not sure what others think. A no-op for now seems like the safest thing to do.) Another option would be to land this as it is (because it tests existing behavior) and then open a pull request to change the behavior and the test. But I think changing the behavior now is probably appropriate. |
@Trott I agree, let's change to no-op so that no-one will be affected. Actually I would also go further: let's keep this behavior consistent between |
@Trott I'll make this change and update the test. Should I make the changes for headers, trailers, trailersDistinct in the same PR then? |
Yes, I think doing that all at once makes sense. We may need to talk about the semver-ness of this change, but regardless, we should land that change on the |
29db476
to
56fb2f4
Compare
56fb2f4
to
9058606
Compare
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.
LGTM!
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.
lgtm
@mcollina @ShogunPanda Do you think this is semver patch or semver major? And do you think this should be documented in doc/api/http.md somewhere? |
I think this is semver major. |
I think is semver-minor instead. The outfacing API hasn't changed and the writability of the fields was never documented. If we speak about backward API compatibility, the change is compatible as what application get after parsing requests/response has not changed, if we exclude eventual fields set by the user (which was private/undocumented). |
+1 on a minor but let’s flag it as “baking for LTS” and see if it breaks somebody before hack porting? |
I agree! |
Landed in 4d723c7 |
PR-URL: #45176 Reviewed-By: Paolo Insogna <paolo@cowtech.it> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
PR-URL: nodejs#45176 Reviewed-By: Paolo Insogna <paolo@cowtech.it> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
PR-URL: #45176 Reviewed-By: Paolo Insogna <paolo@cowtech.it> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
I've received a report of a failure seemingly related to this change (tus/tus-node-server#320 (comment)), marking as |
HTTP server mocking and expectations library for Node.js |
I'm still don't really agree is a semver-major, as the API was undocumented and, IMHO, private and thus not subject to semver). |
Anything reachable is public. |
I strongly disagree on this, given the nature of JavaScript. Now, with this I don't want to say that we can do whatever we want with node internals because people are relying on our actions, obviously. So we try to be as conservative as we possibly can. |
The nature of JavaScript is that closures, and class private fields, are the only way to make anything "private". Everything else is public. |
Given that there's consensus that it is acceptable to re-land this as a semver-major (even if there's disagreement on whether that's preferable), I would love to see us not use this PR to discuss what is and isn't public API. Or if that discussion must happen, maybe it can happen over in #45510 so that we don't splinter the conversation. Or even better, maybe the "what is/isn't public" question can be discussed in its own dedicated issue. |
No description provided.