-
Notifications
You must be signed in to change notification settings - Fork 564
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
feat: http caching #3562
feat: http caching #3562
Conversation
Would it maybe be better to use jsdoc types rather than separate type definition files? @mcollina |
I think using type definitions are in line with the rest of the codebase, and therefore the correct implementation. If we want to migrate to a jsdoc-generated world, let's discuss in another issue! |
e07e3ec
to
938fa7a
Compare
Implements bare-bones http caching as per rfc9111 Closes nodejs#3231 Closes nodejs#2760 Closes nodejs#2256 Closes nodejs#1146 Co-authored-by: Carlos Fuentes <me@metcoder.dev> Co-authored-by: Robert Nagy <ronagy@icloud.com> Co-authored-by: Isak Törnros <isak.tornros@hotmail.com> Signed-off-by: flakey5 <73616808+flakey5@users.noreply.github.com>
938fa7a
to
f69a8b2
Compare
Signed-off-by: flakey5 <73616808+flakey5@users.noreply.github.com>
Signed-off-by: flakey5 <73616808+flakey5@users.noreply.github.com>
Signed-off-by: flakey5 <73616808+flakey5@users.noreply.github.com>
Co-authored-by: Robert Nagy <ronagy@icloud.com>
Co-authored-by: Carlos Fuentes <me@metcoder.dev>
Signed-off-by: flakey5 <73616808+flakey5@users.noreply.github.com>
Signed-off-by: flakey5 <73616808+flakey5@users.noreply.github.com>
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.
headers could be null or undefined
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.
@ronag
Should we use fastTimers?
} | ||
|
||
Promise.resolve(stream).then(handleStream).catch(err => handler.onError(err)) | ||
|
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.
why wrap it?
Promise.resolve(stream).then(handleStream).catch(handler.onError) |
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.
The result of createReadStream
can be a promise
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 should try to avoid that. Promises and streams do not play well together, and there are a few horrid edge cases to be aware of when building such APIs, specifically related to error handling. I would prefer for this to not be a promise.
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 would prefer for this to not be a promise.
From what I see, stream
here is coming from CacheStore
's createReadStream
. People may bring their cache store implementation, and depending on the implementation the returned value could be a Promise<ReadableStream>
, and IMHO undici should accept that.
Let's say, what happens if someone is using redis as their cache backend and all ioredis
APIs are async.
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.
actually this was not about promise or not. it was about the unnecessary wrapping in an anonymous function.
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.
found some issue, which need some love ;)
Co-authored-by: Aras Abbasi <aras.abbasi@googlemail.com>
Co-authored-by: Aras Abbasi <aras.abbasi@googlemail.com>
Signed-off-by: flakey5 <73616808+flakey5@users.noreply.github.com>
Co-authored-by: Aras Abbasi <aras.abbasi@googlemail.com>
Co-authored-by: Aras Abbasi <aras.abbasi@googlemail.com>
Signed-off-by: flakey5 <73616808+flakey5@users.noreply.github.com>
I will review it shortly ;) |
// https://www.rfc-editor.org/rfc/rfc9111.html#name-age | ||
const age = Math.round((Date.now() - value.cachedAt) / 1000) | ||
|
||
value.rawHeaders.push(AGE_HEADER, Buffer.from(`${age}`)) |
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.
value.rawHeaders.push(AGE_HEADER, Buffer.from(`${age}`)) | |
value.rawHeaders.push(AGE_HEADER, Buffer.from(age)) |
const CacheRevalidationHandler = require('../handler/cache-revalidation-handler') | ||
const { UNSAFE_METHODS } = require('../util/cache.js') | ||
|
||
const AGE_HEADER = Buffer.from('age') |
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 am not entirely sure why age
here is lowercased. If it is Age
, we can re-use getWellKnownHeaderBuffer
.
Guys. Please stop with the nits for now and open follow up PRs.we need to land this. |
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, we can do the rest in issue.
@Uzlopak can you take another look?
Co-authored-by: Aras Abbasi <aras.abbasi@googlemail.com>
Co-authored-by: Aras Abbasi <aras.abbasi@googlemail.com>
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 dont see any obvious code smell any more. :)
LGTM
Unrelated Test is flaky. see #3731 |
Implements bare-bones opt-in http caching as per rfc9111. Bare-bones in this case means what's required by the spec and a few extra bits, with more coming in future prs.
Opening as a draft since there's still some more work to be done (mostly tests, but a bit more functionality-wise)No request cache directives are supported at this time, this will come later.
Response caching directives supported:
public
private
s-maxage
max-age
Expires
headerno-cache
no-store
stale-while-revalidate
This relates to...
Closes #3231
Closes #2760
Closes #2256
Closes #1146
Changes
Features
Bug Fixes
n/a
Breaking Changes and Deprecations
n/a
Status