maskit commented on PR #12338: URL: https://github.com/apache/trafficserver/pull/12338#issuecomment-3081816921
> Seems odd to create a new scheme for uds and convert the existing scheme to it. I would use port 0 to designate UDS. I took a look to see what Nginx does and hey use UDS file name as the port value. Nice thing about this approach is you can have multiple UDS "ports" for different services. I already considered those options. Those were my first idea and I tried to implement those, but I concluded that those are not really feasible options unless we make a significant change. Having a UDS filename as a port value would make the URL malformed. The port portion cannot have a string. This is not only about the parser, but also the data structure. We would have to change URLImpl structure, and I suppose that affects cache. On the other hand, use of "+" in the scheme is allowed by the spec. The idea is from "git+ssh", application + transport, although the format is not standardized. Using port number 0 is also problematic, because we have code to auto complete a port number based on the scheme (see `URL::port_get`). Port 0 can only mean that the port information is omitted. This is also the reason why requests for UDS have to use `map_with_recv_port`. If `map` is used, the port information in HTTP request needs to be used by the definition, and most clients do not have the default port number (80 or 443) for a scheme. So ATS does the auto completion, and use 80 or 443, then such requests never match with remap rules that have port number 0 even if we could have such rules (again, omitting a port number, or using 0 let ATS auto complete a port number, so we cannot have such rule). The special scheme indicate that the port number is unavailable, not omitted. Like you pointed out, a limitation of this implementation is that it cannot distinguish multiple UDS file paths. Some might want to specify UDS file path for a remap rule. I'm not sure how the file path should be given but I wouldn't reject the need. However, I think changes for that should be on top of this change. In the future, we might have support for named pipe as well. Then we'd need a way to distinguish UDS and named pipe. Maybe "http+pipe://" ? -- 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]
