Skip to content

Commit

Permalink
Explicitly disallow fetch() caching
Browse files Browse the repository at this point in the history
For the sake of our customers, I don't feel it's worth us fighting that "this implementation is wrong" with our customers in the middle.

If this hack were specific to an implementation of fetch, I'd feel differently, but given this is in the spec, and we're just being overly explicit, rather than relying on a "default" behavior, I'm more ok with it.

I still firmly disagree with implementations that are choosing to cache POST, _especially_ also with an Authorization header, but there's only so much I/we can control.

See context: vercel/next.js#46856

Fixes: #101 #99
  • Loading branch information
mattrobenolt committed Apr 5, 2023
1 parent 47d8561 commit 4cb7502
Showing 1 changed file with 9 additions and 1 deletion.
10 changes: 9 additions & 1 deletion src/index.ts
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,7 @@ type Req = {
method: string
headers: Record<string, string>
body: string
cache?: string
}

type Res = {
Expand Down Expand Up @@ -265,7 +266,14 @@ async function postJSON<T>(config: Config, url: string | URL, body = {}): Promis
'Content-Type': 'application/json',
'User-Agent': `database-js/${Version}`,
Authorization: `Basic ${auth}`
}
},
// XXX: this should be overly redundant and the default behavior should be sufficient,
// since we both are a POST request and send an Authorization header, this request should
// by all means be considered an "unsafe" request for caching purposes. But it seems some
// implementations think differently, so I don't see harm in being overly explicit, since
// this `cache` argument is a part of the actual Fetch API spec anyways. We're just opting
// out of the default behavior.
cache: 'no-store'
})

if (response.ok) {
Expand Down

0 comments on commit 4cb7502

Please sign in to comment.