What version of Kimi Code is running?
0.27.0
Which open platform/subscription were you using?
platform.kimi.ai
Which model were you using?
No response
What platform is your computer?
No response
What issue are you seeing?
When accessing kimi web from less powerful devices (e.g. server = Raspberry Pi, client = phone), the loading screen can take about 20 seconds to complete. While checking with DevTools, I notice that static assets aren't cached.
What steps can reproduce the bug?
Run kimi web. Open Chrome DevTools. Observe "Network". Refresh kimi's web page. Check that static asserts files like assets/index-Dy7xs5tu.js are served repeatedly (HTTP 200) instead of serving from cache.
What is the expected behavior?
Assets files should be cached by the browser and skipped serving.
Additional information
Suggested fix: a few lines change.
Add Cache-Control: public, max-age=31536000, immutable to around here:
|
.send(createReadStream(filePath)); |
Note: the 20-second slowness turned out to be primarily caused by another issue, reported separated as #1904.
What version of Kimi Code is running?
0.27.0
Which open platform/subscription were you using?
platform.kimi.ai
Which model were you using?
No response
What platform is your computer?
No response
What issue are you seeing?
When accessing
kimi webfrom less powerful devices (e.g. server = Raspberry Pi, client = phone), the loading screen can take about 20 seconds to complete. While checking with DevTools, I notice that static assets aren't cached.What steps can reproduce the bug?
Run
kimi web. Open Chrome DevTools. Observe "Network". Refresh kimi's web page. Check that static asserts files likeassets/index-Dy7xs5tu.jsare served repeatedly (HTTP 200) instead of serving from cache.What is the expected behavior?
Assets files should be cached by the browser and skipped serving.
Additional information
Suggested fix: a few lines change.
Add
Cache-Control: public, max-age=31536000, immutableto around here:kimi-code/packages/kap-server/src/routes/webAssets.ts
Line 60 in ceb158d
Note: the 20-second slowness turned out to be primarily caused by another issue, reported separated as #1904.