Cache uses just request url as a key
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 30/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- kotlin
- Domain
- networking, security
Research direction
Start with the cache-key logic in okhttp/src/commonJvmAndroid/kotlin/okhttp3/Cache.kt around line 244, then read the linked HTTP caching guidance and the existing cache tests. Determine how private Cache-Control responses should be isolated between users; done means the behavior is covered by tests showing private responses are not shared across different authorization contexts.
Written by the indexing model from the issue text.
Description
The current cache implementation uses request url as a key even when Cache-Control policy is private.
This might lead to leaking data from one user to another, creating security holes in an application.
I would expect it to cache based on request url + authorisation header in case the cache control policy is private, e.g. a hashed combination of these values
- Dominant language
- Kotlin
- Stars
- 47.1k
- Forks
- 9.3k
- Avg merge
- 18h 18m
- Merged PRs (30d)
- 15
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from lysine-dev/okhttp
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
lysine-dev/okhttp#9788 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
lysine-dev/okhttp#9761 · 3 comments ·
Maintainers usually reply within 1 day
-
Remove crossinline `addInterceptor` and `addNetworkInterceptor` overloadsPossibly taken @Amir-Golmoradi claimed this 5 days ago. Openenhancement
Difficulty 3/5 1-2 days Newbie friendliness 58/100
lysine-dev/okhttp#9779 · 1 comment ·
Maintainers usually reply within 1 day
-
HTTP/2 Data padding is not counted toward the connection flow-control window. This deadlocks connections with peers that pad.Possibly taken @Amir-Golmoradi claimed this 5 days ago. Openbug
Difficulty 3/5 1-2 days Newbie friendliness 67/100
lysine-dev/okhttp#9772 · 4 comments ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
lysine-dev/okhttp#9760 · 3 comments ·
Maintainers usually reply within 1 day
All issues in lysine-dev/okhttp
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
rustyrazorblade/easy-db-lab#1017 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
callstack/react-native-brownfield#492 · 1 comment ·
Maintainers usually reply within 4 days
-
fix: retain the best partial noise-correction solutionPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
world-federation-of-advertisers/cross-media-measurement#4653 ·
Maintainers usually reply within 1 day