I think something like the ACL Filters functionality is the right way to do what you want -- there is already "@in_ip" to select mappings based on the IP address on which the request was received. Based on that, I would propose adding a parameter "@in_proto" that can take values "unix", "http", "http2", etc. You can then create different mapping rules that are selected based on incoming protocol without modification to the target schema.
Digging in a bit more to my thought process that led to this, I think there are two separate matters to consider here. The first is HTTP over sockets. This isn't really HTTP(/[12]) if it's not over TCP, nor HTTP/3 if it's not over QUIC, is it? The addressing schema for unix sockets is different, because in the general sense of trying to address an origin over a socket we're referring to a socket path rather than a hostname or IP address. From ATS' perspective (as a reverse proxy, at least) the only things that matter are the Host header and the request target, but it's worth considering how a theoretical client would be addressing HTTP-over-socket. It looks like WHATWG had some inconclusive discussion on this back in 2021, and it's worth reviewing that issue first: https://github.com/whatwg/url/issues/577 More importantly, though, modifying the target schema for translating the map target based on how it arrived to ATS feels like an abstraction violation. There isn't how we currently remap differently based on received interface, or IP address ("@in_ip" ACL Filters), and we don't support this based on protocol (HTTP/1 vs 2 vs 3). (The closest is map_with_recv_port, which is minimally documented and I'm not entirely certain what it does.) This says to me that mis-using the schema part of the map target is not the right way to solve your problem. Therefore, I think an "@in_proto" extension for the ACL Filter mechanism is most parallel to the existing map language. Regards, --Jered ----- On Aug 21, 2025, at 6:06 PM, Masakazu Kitajo mas...@apache.org wrote: > I am not sure if I understand your question, here's the reasons for > introducing a new scheme for ATS remap rules: > > I have a use case that needs to distinguish requests received on an IP > interface and ones received on a Unix Domain Socket. Having different remap > rules for those two allows me to use different remap plugin settings. Does > that make sense? > > Unix Domain Socket is different from one for TCP/IP. There isn't a port > number for it. As far as I know, there is no standardized way to indicate > the use of Unix Domain Socket, and I think the scheme portion is the only > field that we can use without violating RFC 3986. Although the new scheme > "http+uds" is not standardized, external libraries for parsing/generating > URLs should be able to handle it. > > I hope these answers your questions. > > Thanks, > Masakazu > > > On Wed, Aug 20, 2025 at 2:24 PM Randy DuCharme <radio.ad...@gmail.com> > wrote: > >> APIs can be anything. There's hundreds of ports available. Why >> standardize the unstandard? >> >> Randall DuCharme (Radio *AD5GB*) >> Powered by Open Source software. >> >> >> On Wed, Aug 20, 2025, 15:22 Randy DuCharme <radio.ad...@gmail.com> wrote: >> >> > Why? >> > >> > Randall DuCharme (Radio *AD5GB*) >> > Powered by Open Source software. >> > >> > >> > On Wed, Aug 20, 2025, 15:21 Masakazu Kitajo <mas...@apache.org> wrote: >> > >> >> Hi, >> >> >> >> I recently proposed a way to support remap rules that only match with >> >> requests that are made on Unix Domain Socket, and I'd like to request >> for >> >> comments. >> >> https://github.com/apache/trafficserver/pull/12338 >> >> >> >> My proposal is to introduce a special URL scheme "http+uds" (and >> >> https+uds) >> >> and use it with map_with_recv_port keyword (the keyword is uncommon but >> >> not >> >> new). >> >> >> >> Example: >> >> map_with_recv_port http+uds://service.example http://origin.example/ >> >> >> >> I originally thought of using a special port number/string instead of >> the >> >> new scheme, but it didn't seem practical to me because it'd require a >> lot >> >> of changes in code. In a nutshell, having characters at the port portion >> >> of >> >> a URL is not allowed by the standard, and we'd have to change the URL >> >> parser and also the data structure, which affects cache data. With that >> >> said, that is a difficulty in the implementation. I'd appreciate and >> >> respect comments from users as well. >> >> >> >> Thanks, >> >> Masakazu >> >> >> >
