Repository navigation
Proposal: HTTP – Move bodyHead to data event #550
Description
Activity
a40133d basically tried to fix this, resulting in nodejs/node-v0.x-archive#5557
- addedhttpIssues and PRs related to the http subsystem.Issues and PRs related to the http subsystem.
on Jan 23, 2015 Aye, I was talking to nathan when I created this ticket, it would indeed be a breaking change, it would hurt, but it'd mean a more consistent API.
– Micheil
On 22 Jan 2015, at 05:37, Nathan Zadoks notifications@github.com wrote:
https://github.com/joyent/node/commits/a40133d10cdb911b27fe8d46d67a835b0103bbf1 basically tried to fix this, resulting in nodejs/node-v0.x-archive#5557
—
Reply to this email directly or view it on GitHub.I'd definitely like to see this fixed — I think this legacy cruft has lived for long enough. I'd have vetoed the original node revert if I could.
Relevant (but old) node.js issue/pr: nodejs/node-v0.x-archive#3036
Maybe also related to nodejs/node-v0.x-archive#4813
@miksago How does this relate to nodejs/node-v0.x-archive#4813? Does one override the necessity of the other?
I think nodejs/node-v0.x-archive#4813 closes this nicely.
Actually it would be better if this were to close the joyent/node issue. :)
- addedfeature requestIssues requesting new Node.js features.Issues requesting new Node.js features.
on Jun 25, 2015 - addedsemver-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.
on Mar 11, 2016 Is this still something we'd want to do?
- addedstalledIssues and PRs manually marked as stalled and scheduled for automatic closure.Issues and PRs manually marked as stalled and scheduled for automatic closure.
on Apr 9, 2016 Unfortunately, given the lack of any further discussion or action on this, I'm going to close. We can reopen and revisit later if necessary.
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?