You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Masakazu Kitajo <ma...@apache.org> on 2025/08/20 20:21:00 UTC
[RFC] Remap rules for requests made on Unix Domain Socket
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
Re: [RFC] Remap rules for requests made on Unix Domain Socket
Posted by Jered Floyd <je...@convivian.com>.
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 maskit@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 <ra...@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 <ra...@gmail.com> wrote:
>>
>> > Why?
>> >
>> > Randall DuCharme (Radio *AD5GB*)
>> > Powered by Open Source software.
>> >
>> >
>> > On Wed, Aug 20, 2025, 15:21 Masakazu Kitajo <ma...@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
>> >>
>> >
Re: [RFC] Remap rules for requests made on Unix Domain Socket
Posted by Randy DuCharme <ra...@gmail.com>.
Code more, worry less . Sockets are fun. Enjoy
Randall DuCharme (Radio *AD5GB*)
Powered by Open Source software.
On Thu, Aug 21, 2025, 17:07 Masakazu Kitajo <ma...@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 <ra...@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 <ra...@gmail.com>
> wrote:
> >
> > > Why?
> > >
> > > Randall DuCharme (Radio *AD5GB*)
> > > Powered by Open Source software.
> > >
> > >
> > > On Wed, Aug 20, 2025, 15:21 Masakazu Kitajo <ma...@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
> > >>
> > >
> >
>
Re: [RFC] Remap rules for requests made on Unix Domain Socket
Posted by Masakazu Kitajo <ma...@apache.org>.
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 <ra...@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 <ra...@gmail.com> wrote:
>
> > Why?
> >
> > Randall DuCharme (Radio *AD5GB*)
> > Powered by Open Source software.
> >
> >
> > On Wed, Aug 20, 2025, 15:21 Masakazu Kitajo <ma...@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
> >>
> >
>
Re: [RFC] Remap rules for requests made on Unix Domain Socket
Posted by Randy DuCharme <ra...@gmail.com>.
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 <ra...@gmail.com> wrote:
> Why?
>
> Randall DuCharme (Radio *AD5GB*)
> Powered by Open Source software.
>
>
> On Wed, Aug 20, 2025, 15:21 Masakazu Kitajo <ma...@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
>>
>
Re: [RFC] Remap rules for requests made on Unix Domain Socket
Posted by Randy DuCharme <ra...@gmail.com>.
Why?
Randall DuCharme (Radio *AD5GB*)
Powered by Open Source software.
On Wed, Aug 20, 2025, 15:21 Masakazu Kitajo <ma...@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
>