ts
export const onRequest = (context) => {
  return new Response(context.env.SOME_API_KEY)
}

Should do it!

I tried doing it like I did with a just a regular worker secret, also did not work

Gotcha 👍

context

has a bunch of things in it, including

env

which holds all your bindings.

Thank you!

I also ran into this issue trying to use middleware to append a cookie to an existing response (created by a previous handler). I assumed it was due to

set-cookie

being a "Forbidden response header name" 👻 (https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_response_header_name). I had to do something like this to create an entirely new response with the right headers:

js
let originalResponse = await next();
let headers = new Headers(originalResponse.headers);
headers.append("set-cookie", "test=123");
let response = new Response(originalResponse.body, { status: originalResponse.status, headers });

is it possible to prevent certain files from being converted into workers?

If you don't export the magic handlers (

onRequest

,

onRequestGet

etc.) the file is ignored.

ah. that's nice

There's a known bug about failing to parse non-JS files (e.g.

tsconfig.json

), but we're working on it, and those will be excluded too.

Since we cant deploy pages + functions using wrangler yet, when it is available, will we be able to make use of

wasm_modules

or get access to a resources tab?

Thanks for the advice @User! With your method, the set-cookie headers have no issue in

Wrangler2 pages dev

. It's interesting that when the functions are deployed to the pages platform, you can just append the headers directly (without created a new Header class).

Yeah I wonder if that's because Wrangler2 uses Miniflare (which uses a fork of

node-fetch

to implement things like

Response

and

Headers

). I did just look through the source code and I couldn't see anything in there specifically about

set-cookie

or forbidden response header names though 🤷

This is reproducible without middleware actually. This fails to set the cookie (the header isn't present on the response):

js
// functions/index.js
export function onRequestGet() {
  let res = new Response("hello");
  res.headers.append("set-cookie", "test=123");
  return res;
}

but this works fine:

js
// functions/index.js
export function onRequestGet() {
  let res = new Response("hello", {
    headers: { "set-cookie": "test=123" }
  });
  return res;
}

Ah from looking at my local bundle it appears Wrangler2 might be using Undici now, which does automatically filter out forbidden response headers (https://github.com/nodejs/undici/blob/cd566ccf65c18b8405793a752247f3e350a50fcf/lib/fetch/headers.js#L213-L218). Is it worth opening an issue on the new Wrangler2 repo about the discrepancy between this and deployed Workers?

I'd say it's definitely worth opening an issue, yeah! This might be something with

miniflare

specifically and not

wrangler2

- I'm not sure, but I imagine emulating as closely as possible with local dev and prod is a goal.

Ah yeah, Undici forbids set-cookie

so yeah, report this to Miniflare

Yeah it is Miniflare, but the code in that repo is appears to be out of date with what's running within Wrangler2 on my machine—I assume there are a bunch of internal/unreleased versions—so I ended up opening this on the Wrangler2 repo: https://github.com/cloudflare/wrangler2/issues/59

I can re-open on Miniflare if that would be a better place. This might require a wider Workers discussion, since technically the prod environment isn't following the

fetch

spec right now 😅

There's a

v2

branch in miniflare with the up to date version used in wrangler2 if you wanted to take a look 🙂

That's great though - the issue can always be moved if it makes sense

@User Hey you two.. the

ctc.waitUntil

bug should be fixed and released.. Could you please give it another go and let us know if it fixes both your issues?

Sorry, my fault for confusion there. Should be fixed in the latest

wrangler@alpha

, but not quite in production yet.

This is a

plinko

thing, not Wrangler right?

quick question. I am not sure how to access the KV store I created and assigned to my CG Page in the settings functions. I run the following command (no I have to define the namespace here if so what's the format?) npx wrangler pages dev functions

^ this the code I have written but I excepted the KV variable would show up in the context var

Works for me locally now, thanks 👍 - feel free to ping me again once it got fixed in production and I'll happily give it a test their too

yes but new versions of the Pages Functions syntax don't get automatically rolled out to the Pages build images, that has its own release cycle