Improve how we check if ETag caching is enabled for given request

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Description

Currently in order to check if ETag caching is enabled for a given request, we use regular expressions to check if the request path matches a given pattern. This is difficult and error-prone, because of how unstructured our routes can be.

1. We support multiple levels of nesting because of subgroups (this makes matching from the beginning of the path impossible)
2. We also have cases like /tree/master/pipelines.json (this makes matching from the end of the path insufficient)

We can't rely on our regular routing here, because it hits the database. The whole point of ETag caching is to avoid hitting the database

Proposal

Option 1 - structured routes for non-user-facing endpoints

Introduce new endpoints that have well-defined segments. This allows to easily create regular expressions. Example:

• /projects/:id/pipelines.json
• /issues/:id/rendered_title.json

Disadvantages

This requires changes in controllers, because we will be finding records in a different way.

Option 2 - frontend controls caching

Do not check the request path to determine if ETag caching is enabled. Use a request header or a query parameter to enable ETag caching.

Disadvantages

We push the responsibility to the frontend. Malicious users may enable caching where we want it to be disabled (I'm not sure if it's a real concern).