rawlinp commented on pull request #6017: URL: https://github.com/apache/trafficcontrol/pull/6017#issuecomment-880088861
> And if you're reading immediately after writing, writers should be sending Cache-Control: no-cache That is a fairly large paradigm shift for clients which have historically expected write-read consistency. This is a (mostly) RESTful, HTTP-JSON API, not an HTTP video origin which mostly just provides content without accepting any writes from clients. After updates, TP does an immediate `GET` of the changed resource, and it expects to read the changed resource. If our clients all have to set `Cache-Control: no-cache` from now on to get the old behavior, that is a massively breaking change. This kind of makes me think that the _default_ behavior, if we even add this timed cache, should be to not use the cache for clients. Then, if cache-smart clients (e.g. `t3c`) want to use caching and understand the implications that come with it, then they can pass a header to allow cached responses. > Any client doing a POST and immediate GET without a no-cache or max-age is just lucky it works today, they're ignoring large parts of the HTTP spec. I would argue that most RESTful APIs do _not_ expect clients to understand and implement HTTP caching 100% to spec. Just because something is using HTTP doesn't mean it has to also understand and fully implement HTTP caching. That would be quite a large requirement for something that simply needs to get data from an API. > But moreover, RWR is a cache, keeping it but getting rid of the small-cache doesn't make clients that aren't following HTTP requirements okay. In fact, with a 1s cache, a great many TO requests take longer than that, so the RWR cache is frequently longer than the small-cache, not shorter. Ah, I understand. Forget what I said about just having RWR without a timed cache then. The data consistency issue applies to both. > Nobody is suggesting we turn off the tests, or add sleeps. The tests which immediately POST and GET can send a no-cache, and this PR includes tests for the caching itself. As I mention above, that is a massively breaking change to all TO clients. > A script needing to do that quickly can send a no-cache in its request, and further an Age is sent indicating if the response was cached. Again, this is part of HTTP, and clients are wrong to not be doing it today. Again, I don't think it's a requirement for all RESTful/HTTP-based APIs and corresponding clients to fully implement HTTP caching just because they use HTTP. That doesn't make clients "wrong". > I don't agree. Defaults should be sane. This is something that 99% of ATC operators will want enabled 99%? Only the largest ATC CDNs probably even have issues with DB load caused by `t3c`. If DB load wasn't a problem, I would _strongly_ suggest preferring the existing data consistency over enabling caching. Caching in general adds a lot of variability and problems into a system, and if it can be avoided, it probably should be IMO. Also, the "sane" default in most cases is whatever the pre-existing behavior was. Systems are built around those behaviors, and surprising everyone by changing the behavior they depend on is not good. -- 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]
