That’s another idea. I suppose between PROXY and PP I’d stick with PP.
Brian
"Come to Me, all who are weary and heavy-laden, and I will
give you rest. Take My yoke upon you and learn from Me, for
I am gentle and humble in heart, and you will find rest for
your souls. For My yoke is easy and My burden is light."
~ Matthew 11:28-30
On Sun, Feb 9, 2025 at 11:32 AM Leif Hedstrom <zw...@apache.org> wrote:
> I’m +1 too.
>
> Adding ProxyProtocol seems pretty long, maybe we can use PROXY (all upper
> case) instead of PP, which is how it’s spelled.
>
> — Leif
>
> On Sat, Feb 8, 2025 at 20:03 Brian Neradt <brian.ner...@gmail.com> wrote:
>
>> +1
>>
>> My preference would be to spell out ProxyProtocol in the API instead of
>> PP. But I don't feel that strongly about it though. +1 either way.
>>
>> On Fri, Feb 7, 2025 at 7:21 PM Masakazu Kitajo <mas...@apache.org> wrote:
>>
>>> Hi,
>>>
>>> I'd like to propose a new TS API to access information from PROXY
>>> protocol.
>>>
>>> ATS supports PROXY protocol, which carries connection information
>>> between a client and a LB (basically the 5-tuple). And I recently added the
>>> support for PROXY protocol version 2 TLV (Type-Length-Value) fields, which
>>> carry additional information such as TLS parameters. However, the
>>> information received is currently only available inside ATS core.
>>>
>>> It'd be useful to export the information so that ATS plugins can access
>>> it. An example use case is the Rate Limit plugin. The plugin is currently
>>> almost useless if PROXY protocol is used, because the IP address that the
>>> plugin can use is always the address of a LB, and there's no way to access
>>> the server name in TLS SNI extension if the LB terminates TLS.
>>>
>>> Here's the proposal:
>>>
>>> TSReturnCode TSVConnPPInfoGet(TSVConn vc, uint32_t key, const char
>>> **value, int *length);
>>> TSReturnCode TSVConnPPInfoIntGet(TSVConn vc, uint32_t key, TSMgmtInt
>>> *value);
>>>
>>> enum TSVConPPInfoKey {
>>> TS_PP_INFO_VERSION = 0x10000,
>>> TS_PP_INFO_SRC_ADDR, // Returns a pointer for struct sockaddr
>>> TS_PP_INFO_SRC_PORT,
>>> TS_PP_INFO_DST_ADDR,
>>> TS_PP_INFO_DST_PORT,
>>> TS_PP_INFO_PROTOCOL,
>>> TS_PP_INFO_SOCK_TYPE,
>>> };
>>>
>>> The function type signatures basiclly align with TSHttpTxnInfoIntGet.
>>>
>>> The "key" parameter is a 32 bit integer, although TLV type is a 16 bit
>>> integer on PROXY protocol spec. This is to have a single interface to
>>> access both the 5-tuple and TLV field values. Key value less than 0x10000
>>> (65536) will be considered as a TLV type. Users of TSVConnPPInfoGet are
>>> expected to cast the returned pointer accordingly or parse the returned
>>> data.
>>>
>>> I considered using the existing APIs with auto data source switching
>>> inside the functions, but it's probably not a good idea because ATS will
>>> not be able to access the information from the immediate connection. And
>>> TLV fields can have arbitrary data, thus, we need a new API anyway. So, I
>>> think the existing APIs should work as they are (i.e. returns information
>>> from the immediate connection) so plugins can choose which one to use.
>>>
>>> Thoughts?
>>>
>>> PROXY protocol:
>>> https://www.haproxy.org/download/2.1/doc/proxy-protocol.txt
>>>
>>> Rate Limit plugin:
>>>
>>> https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/rate_limit.en.html
>>>
>>> -- Masakazu
>>>
>>
>>
>> --
>> "Come to Me, all who are weary and heavy-laden, and I will
>> give you rest. Take My yoke upon you and learn from Me, for
>> I am gentle and humble in heart, and you will find rest for
>> your souls. For My yoke is easy and My burden is light."
>>
>> ~ Matthew 11:28-30
>>
>
