Improve performance: Push for the usage of ETag/If-None-Match

[tdelmas]

What is the issue and why is it an issue?

In order to reduce the load both on producers and consumers, caching mechanisms could be improved.

Please describe some potential solutions you have considered (even if they aren’t related to GBFS).

Following the discussion during the International Mobility Data Summit (https://github.com/MobilityData/gbfs/discussions/703), I would like to suggest this addition to the specification in the "File Distribution" section:

• HTTP responses SHOULD include the ETag HTTP header.
• Clients receiving Etags SHOULD use the If-None-Match HTTP header for subsequent requests.
• HTTP responses to requests including the If-None-Match HTTP header SHOULD respect it by returning a 304 Not Modified when appropriate.

Is your potential solution a breaking change?

• [ ] Yes
• [X] No
• [ ] Unsure

[matt-wirtz]

Hi @tdelmas . Always a good idea to reduce load.

I think it's related to this topic: #630 Which addresses the issue of both load and latency but with a complete different mechanism. As long as there is no activity in the regard of #630 I think your suggestion is a nice step in between.

[mobilitydataio]

This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.

[tdelmas]

https://github.com/MobilityData/gbfs/issues/630#issuecomment-2625476342

We are positive to incremental improvements and are looking into https://github.com/MobilityData/gbfs/issues/708 as a stepping stone.

@testower how is your progress on that as a producer?

[testower]

Unfortunately no progress yet @tdelmas but it's on the horizon :)

[mobilitydataio]

This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.

[mobilitydataio]

This discussion has been closed due to inactivity. Discussions can always be reopened after they have been closed.

[mplsmitch]

Reopening this issue now what we have an example case from @testower. I would like add the language proposed above to the "File Distribution" section. Question: Is the above adequate to cover this topic. Anything that should be added, modified, removed?

CC: @tdelmas

[tdelmas]

@davidgamez Please can you re-open this issue?

[testower]

Implementing this between OpenTripPlanner (client) and entur/lamassu aggregator (server), we observe that around 90% of requests are handled with 304 Not Modified response.