jhg03a opened a new issue, #7306: URL: https://github.com/apache/trafficcontrol/issues/7306
<!-- ************ STOP!! ************ If this issue identifies a security vulnerability, DO NOT submit it! Instead, contact the Apache Traffic Control Security Team at [email protected] and follow the guidelines at https://apache.org/security regarding vulnerability disclosure. - For *SUPPORT QUESTIONS*, use the #traffic-control channel on the ASF slack (https://s.apache.org/tc-slack-request) or the Traffic Control Users mailing list (send an email to [email protected] to subscribe). - Before submitting, please **SEARCH GITHUB** for a similar issue or PR * https://github.com/apache/trafficcontrol/issues * https://github.com/apache/trafficcontrol/pulls --> <!-- Do not submit security vulnerabilities or support requests here - see above --> ## This Improvement request (usability, performance, tech debt, etc.) affects these Traffic Control components: <!-- delete all those that don't apply --> - Traffic Ops ## Current behavior: Currently TO has no restrictions on if or what cidr ranges may be applied to a server IP address. In some use cases and contexts this is required information, such as server provisioning. Humans are inconsistent however and don't always include this information either by accident or because they meant only a single ip address. Any downline TO API consumer has to include special parsing logic for IP addresses to handle cases where maybe it's included and maybe it's not. Depending on testing sample size and bad luck, you might not realize this is the case and end up throwing preventable errors. ## New behavior: <!-- Describe how this change would improve Traffic Control --> I propose that for GET operations on the server object the lack of a cidr range should automatically append a `/32` or `/128` subnet accordingly in the event a cidr range is missing. This brings consistency to the output, while still allowing users not to have to think about it when they mean a single ip address. Given that any consumer of the API already has, or should, handle this inconsistency and either drop the cidr if they don't want it or glue it in if they do, this should be a safe change to make on an existing TO API version. This does not attempt to address if the cidr range provided by a human makes any sense such as `/0`. If it is more desirable for the data to be consistent in TODB, this could alternatively be applied as an input restriction on TO and TP along with a migration to correct existing data; thus forcing the user to think about their input more. -- 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]
