Define the browser algorithm for determining cacheability of status codes
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 1.3k
- Forks
- 125
- PR merge metrics
- No merged PRs in 30d
Description
#326 leaves the loading spec more restrictive than the RFC draft in terms of which status codes are allowed. We should figure out how browsers implement https://httpwg.org/http-core/draft-ietf-httpbis-cache-latest.html#response.cacheability and refer to that from the loading spec instead of blindly requiring only status 200, or we should tighten the RFC draft to require just that status.
Contributor guide
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.
Research direction
Start with issue #326, the loading spec's status-code requirement, and the linked HTTP core draft section on response cacheability. Compare how browsers determine cacheability, then document whether the loading spec should reference that algorithm or whether the RFC draft should require only status 200.
Written by the indexing model from the issue text.
Assessment
- Domain
- networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100