api: support a "304 Not Modified" responses with empty body
- Dominant language
- Go
- Stars
- 30.1k
- Forks
- 4.6k
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 39
Description
This is a re-framing of #7968.
### Motivation ###
Even with the introduction of the streaming backend there are still a number of places where serializing of responses takes a significant amount of CPU time. By returning a `304 Not Modified` response from the API endpoint we remove the need to serialize a response, which removes all the wasted CPU time.
This change would reduce wasted CPU time on any client or server agent which handles API requests, any time an HTTP blocking request times out. This applies to both the blocking query backend **and the streaming backend**.
### Implementation ###
Returning this new response code by default would be a breaking change. How should requests opt-in to this new response code? Likely an HTTP request header.
### Future improvements
#3871 covers how this support could be used with more common HTTP headers (`If-None-Match`, `ETag`) to allow browsers to use this caching.
Contributor guide
Research direction
Start by reading the prior issue #7968 and the related caching issue #3871. Define how requests opt in to 304 Not Modified responses with empty bodies, covering both blocking-query and streaming backends; done means the approach is specified well enough to implement without a breaking default change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100