-
-
Notifications
You must be signed in to change notification settings - Fork 37.3k
Proposal: HTTP – Move bodyHead to data event #550
Copy link
Copy link
Closed
Labels
feature requestIssues requesting new Node.js features.Issues requesting new Node.js features.httpIssues and PRs related to the http subsystem.Issues and PRs related to the http subsystem.semver-majorPRs that contain breaking changes and should be released in the next major version.PRs that contain breaking changes and should be released in the next major version.stalledIssues and PRs manually marked as stalled and scheduled for automatic closure.Issues and PRs manually marked as stalled and scheduled for automatic closure.
Description
Activity
Metadata
Metadata
Assignees
Labels
feature requestIssues requesting new Node.js features.Issues requesting new Node.js features.httpIssues and PRs related to the http subsystem.Issues and PRs related to the http subsystem.semver-majorPRs that contain breaking changes and should be released in the next major version.PRs that contain breaking changes and should be released in the next major version.stalledIssues and PRs manually marked as stalled and scheduled for automatic closure.Issues and PRs manually marked as stalled and scheduled for automatic closure.
So, ages and ages ago, for WebSockets support, the idea of an upgradeHead was added. This is for the data that directly trails the headers in a Upgrade or Connect request. Whilst the spec doesn't really say what this is, I propose making this as the first data event, rather than as a extra argument to the
upgradeorconnectevents.This seems like the better way to do this, although, I know it'd be a huge change in API from what we currently have, which is fairly popularly used at present.
I feel that we should've really implemented it this way round in the first place, but there were a whole bunch of reasons as to why this proved difficult at the time.
Thoughts?