rawlinp commented on pull request #6017: URL: https://github.com/apache/trafficcontrol/pull/6017#issuecomment-880250328
That's a good point @dneuman64. If we decide to give up data consistency, it should really only affect TO API v4+. Otherwise, once 6.0 is cut, it should really only affect TO API v5+, and we should really try to have some kind of stability instead of breaking clients in every ATC release. However, if this behavior were opt-in on the client-side rather than opt-out, we wouldn't have to change our clients at all, and this wouldn't be a breaking change. I know that is counter to the HTTP spec, but this is an API that has been around for quite a long time. When APIs have a certain behavior for a very long time, the ecosystem begins to depend on that behavior (and it definitely does). `t3c` is responsible for almost the entire load on TODB, and it would be really nice to make _it_ be cache-smart by having it send a header to TO that says "you can give me cached content", rather than requiring every other client to send `cache-control: no-cache`. Again, I realize that goes against the HTTP spec @rob05c, but that seems like the best way forward to maintain API stability. Perhaps we can also add a TO config option, e.g. `disable_opt_in_for_caching`, which we can set to `true` once all the TO API clients are cache-smart, at which point clients would have to opt-out of caching via `cache-control: no-cache`. Does that sound agreeable? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
