-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
fix(ext/node): handle 'upgrade' responses #19412
fix(ext/node): handle 'upgrade' responses #19412
Conversation
|
} | ||
|
||
#[op] | ||
pub async fn op_fetch_send( | ||
state: Rc<RefCell<OpState>>, | ||
rid: ResourceId, | ||
into_byte_stream: bool, |
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.
not a big fan that we have this option and also the op.
Is there a considerable perf difference if we do have this option and call the two ops after each other for fetch?
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.
Probably not - let's use this option for now - we will be rewriting all of that code to drop reqwest
and we can clean it all up then.
state | ||
.borrow_mut() | ||
.resource_table | ||
.add(FetchResponseResource { |
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.
I think we can clean this up down the line so that we always create a FetchResponseResource
that can internally either be the full response, or deconstructed into a stream (an inner enum). And FetchResponseBodyResource
goes away. The first read would deconstruct automatically. This is what we used to do for HTTP too - not sure if we still do that.
That way the caller would not have to choose whether they want to deconstruction or not. Depending on which ops you use later, it either happens or not.
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.
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.
It's ok to land as is, but we should clean this up soon.
incoming.upgrade = null; | ||
|
||
for (const [key, _value] of res.headers) { | ||
if (key.toLowerCase() === "upgrade") { |
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.
I guess we don't use primordials in Node code, right?
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.
Correct
44f50d2
to
6221008
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
Addresses feedback from #19412 (comment)
Addresses feedback from #19412 (comment)
@bartlomieju but how to use the puppeteer product? Using their https://github.com/puppeteer/puppeteer/tree/main#readme example script, it fails downloading the chrome testing binary (= default node behaviour).
Also @lucacasonato example: #18913 targeting puppeteer-core is not working against the latest puppeteer version since the Does this changeset target npm:puppeteer OR npm:puppeteer-core compatibility? |
@jeroendee Something like this ensures that chrome is available before launching puppeteer: import { DenoDir } from "https://deno.land/x/deno_cache@0.4.1/mod.ts";
import { join } from "https://deno.land/std@0.190.0/path/mod.ts";
import puppeteer, { Page, PUPPETEER_REVISIONS } from "npm:puppeteer-core";
import * as puppeteerBrowsers from "npm:@puppeteer/browsers";
async function launchPuppeteer(options: PuppeteerLaunchOptions = {}) {
const dir = new DenoDir();
const path = join(
dir.root,
"puppeteer",
"chrome",
PUPPETEER_REVISIONS.chrome,
);
const install = await puppeteerBrowsers.install({
cacheDir: path,
browser: puppeteerBrowsers.Browser.CHROME,
buildId: PUPPETEER_REVISIONS.chrome,
});
const executablePath = puppeteerBrowsers.computeExecutablePath({
browser: install.browser,
buildId: install.buildId,
cacheDir: path,
});
return await puppeteer.launch({
...options,
executablePath,
});
} |
This commit adds support for "upgrade" events in "node:http"
"ClientRequest". Currently only "Websocket" upgrades are
handled. Thanks to this change package like "npm:puppeteer"
and "npm:discord" should work.
Closes #18913
Closes #17847