rawlinp commented on pull request #5974: URL: https://github.com/apache/trafficcontrol/pull/5974#issuecomment-876008125
So, I agree that we should try to reduce duplication as much as possible, but I'm not sure that changing the entire direction of this PR to use middleware is really appropriate for this. When I think of middleware, I think of things that generally apply to all routes (authorization, setting response headers, gzipping responses, etc.). These locking checks are somewhat specialized per route and depend on what is being modified. Somehow the middleware would have to know which CDNs were being modified, then check those against the current CDN locks. That means the route would have to set the CDN list in the request context (probably), and the middleware would have to get those out of the request context (after the request has been "handled successfully" as far as the handler knows) to run the check (which might fail). So where we're getting the CDNs and where we're checking the CDNs would be two totally different areas of the code (which isn't great IMO). Maybe there is another way to do it better with middleware, but that is just the idea that came to mind. It just doesn't seem like a good fit. On the plus side, CDN locking should be unnecessary once we complete the plan for DS and server snapshots, so we should be able to deprecate and remove CDN locks once we get to that point. But in the meantime, they will tide us over. -- 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]
