Open PoneyClairDeLune opened 2 years ago
Hello! I've been following that issue too, and saw the backlink to this issue a while ago so I thought I'd chime in! Deno recently (as of v1.36) merged a way to send Host headers via the Deno.createHttpClient
. See the test case here:
https://github.com/denoland/deno/blob/5cb1d18439f562c8004a941b0f56ed034a44b052/cli/tests/unit/fetch_test.ts#L1572-L1589
const client = Deno.createHttpClient({
allowHost: true,
});
const res = await fetch("http://localhost:4545/echo_server", {
headers: {
"host": "example.com",
},
client,
});
(Note that you need to run deno with --unstable
to have access to Deno.createHttpClient
)
@LucienLeMagicien Many thanks for chiming in! I was almost starting to look to port adobe/fetch to Deno... Work relieved!
My pleasure! It seems you're not aware of this either (since you were looking at reimplementing a module), so just so you know: Deno can now also use npm modules directly, and the "Node.js compatibility layer" is pretty good (and they track compatibility issues in their issues). Since v1.28 (https://deno.com/blog/v1.28) you can do things like import axios from "npm:axios"
or import nodefetch from "npm:node-fetch"
.
(The Host header also didn't work when doing this at first, but they fixed it (in v1.34) after I opened an issue :ok_hand:)
@LucienLeMagicien I was seeking to re-implement because I wanted it to be either runtime-native or runtime-agnostic. Tbh I hate Node.js and it's ecosystem, and I've been a vocal opposer for Deno to add direct Node.js compatibilities. I wish for a runtime complying with mutually agreed-upon standards, not one adding it's own sauces to do nearly everything. Still, thanks for pointing it out!
Thanks to denoland/deno#11017, Deno effectively disabled all domain fronting attempts. Apparently Deno's coreteam considers server-side code as users. A modified fetch implementation might be required to bypass this restriction.
Cloudflare Workers also disabled domain fronting via workers.