rawlinp commented on pull request #6017: URL: https://github.com/apache/trafficcontrol/pull/6017#issuecomment-880167098
> 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. At the HTTP layer, our clients are handling the protocol just fine, and they would handle it just fine (at the HTTP layer) if they were to receive cached responses. It's about breaking the _application_/business logic layer that matters. Plain and simple, everything that uses the TO API has depended on write-read consistency since its inception. When you take that away, everything in the application/business logic layer that depended on that consistency is now broken. In order to fix the brokenness, we'd be requiring every single TO API client to implement cache-control headers. This is no different than breaking clients by adding new required fields to an existing API. Why is it ok to break clients through data inconsistency but not ok to break clients through adding new required fields to an existing API? It's not ok to force clients to just start sending the new required field, but it's ok to force clients to send cache-control headers now? -- 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]
