rob05c commented on pull request #6017: URL: https://github.com/apache/trafficcontrol/pull/6017#issuecomment-880141245
> 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. It doesn't seem like a large requirement. HTTP only has 7 client Cache-Control directives, and clients only need to send 1 to not be broken, either max-age or no-cache, and only under the very specific scenario when they need to get data they just sent. > 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". That does make clients wrong, and broken. They are ignoring and violating the spec. RFC 7230§2.4: > Any client or server MAY employ a cache RFC 7231§4.3.1 > The response to a GET request is cacheable; a cache MAY use it to > satisfy subsequent GET and HEAD requests unless otherwise indicated > by the Cache-Control header field Therefore, any client which fails to behave correctly after not sending a Cache-Control and receiving a cached response is broken, and any client which requires that an HTTP server MUST NOT send a cached response without a Cache-Control indicating so is violating the HTTP spec. I strongly oppose any ATC clients and servers failing to implement parts of HTTP, especially HTTP Caching, as though a partial protocol were not fundamentally broken and extremely bug-prone. HTTP and HTTP Caching are extremely thoroughly thought-out by extremely smart people, and the protocol handles very nearly every conceivable scenario. Moreover, as above, it's not particularly large or difficult to implement. Failing to implement parts as required is dangerous and bug-prone. Even aside from this feature, we need to fix any broken clients. If we happen to not use JSON arrays, and some clients have JSON libraries that don't implement arrays, and we add an endpoint that uses JSON arrays, surely nobody would say the client was reasonable for not implementing that part of the JSON protocol. In general, you can't just ignore parts of any protocol. In this particular case, the only thing necessary for clients to not be broken is, in the very specific case that they sent data and need to retrieve that data, sending a `no-cache` or `max-age` since the time the data was sent. That doesn't seem large, or surprising, or unreasonable. -- 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]
