You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Brian Neradt <br...@gmail.com> on 2020/07/08 02:52:18 UTC
New TS APIs: server side protocol stack and client cert information
Hi dev@trafficserver.apache.org,
This is for a TS API update review.
To support some Traffic Dump features, I'd like to update the TS API in the
following ways:
1. Add TSHttpTxnServerProtocolStackGet
and TSHttpTxnServerProtocolStackContains. These are the server-side
analogues to the already existing client-side functions.
2. TSHttpTxnServerVConnGet: This is a TSHttpTxn version of the already
existing TSHttpSsnServerVConnGet. This allows a user to get the
server-side NetVconnection from a transaction.
3. TSVConnProvidedSslCert: This builds off of Susan's PR
https://github.com/apache/trafficserver/pull/6699 by exposing a method
to query whether a TLS cert was provided to the peer on the virtual
connection.
The following Traffic Dump PR has these updates:
https://github.com/apache/trafficserver/pull/6972
Note the PR contains doc updates describing each of these functions. See
the first three files listed in the files section of the PR:
https://github.com/apache/trafficserver/pull/6972/files
Please let me know if there are any concerns or suggestions for improvement
concerning this.
Thanks,
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
Re: New TS APIs: server side protocol stack and client cert information
Posted by Alan Carroll <so...@verizonmedia.com.INVALID>.
It may be simpler but it is still not completely determined.
On Wed, Jul 8, 2020 at 10:28 AM Sudheer Vinukonda
<su...@yahoo.com.invalid> wrote:
> Right, I understand that. But, the server side protocol stack isn’t as
> varied or has anywhere as many combinations as the client side and is
> largely determined by system wide setting on the ATS side, no? I suppose it
> may add some sort of symmetry, but I wonder if it somehow feels
> superfluous.
>
>
Fw: New TS APIs: server side protocol stack and client cert
information
Posted by Sudheer Vinukonda <su...@yahoo.com.INVALID>.
----- Forwarded Message ----- From: Sudheer Vinukonda <su...@yahoo.com>To: "dev@trafficserver.apache.org" <de...@trafficserver.apache.org>Sent: Wednesday, July 8, 2020, 12:50:41 PM PDTSubject: Re: New TS APIs: server side protocol stack and client cert information
Yeah, I'd *think* most of what is needed should be part of the configs (including overridables) which should be available through using standard config get API. For e.g, to check if the Server connection is HTTPS or not, TSUrlSchemeGet() may be used. TSHttpTxnServerAddrGet() should give the port and IP protocol used and if the Server connection is a TLS connection, the configs "proxy.config.ssl.client.*". should indicate what is active on a given TXN.
To be clear, I'm not necessarily -1 on the new API, but, just wanted to point that, unlike the client connections, the protocol stack to be used for Server connections is controlled directly by ATS and is mostly derived from local configs, so, it just seems a little redundant to have a separate TXN API for outbound protocol stack.
Thanks,
Sudheer
On Wednesday, July 8, 2020, 10:59:10 AM PDT, Brian Neradt <br...@gmail.com> wrote:
Is there another way for Traffic Dump to know what the protocol stack is on
the server side on a per transaction basis? Without this server-side API,
it seems it would not be easy for Traffic Dump or any plugin to get this
information. It is being added to satisfy a need Traffic Dump has. As you
point out, it adds something of a symmetry that already exists as a
precedent on the client side.
Thank you for your thoughts.
Brian
On Wed, Jul 8, 2020 at 10:28 AM Sudheer Vinukonda
<su...@yahoo.com.invalid> wrote:
> Right, I understand that. But, the server side protocol stack isn’t as
> varied or has anywhere as many combinations as the client side and is
> largely determined by system wide setting on the ATS side, no? I suppose it
> may add some sort of symmetry, but I wonder if it somehow feels
> superfluous.
>
> > On Jul 8, 2020, at 8:12 AM, Susan Hinrichs <sh...@verizonmedia.com.invalid>
> wrote:
> >
> > The TSHttpTxnServerProtocolStackGet and
> > TSHttpTxnServerProtocolStackContains are read only. They do not
> customize
> > the Server protocol stack, but they give the plugin the ability to
> analyze
> > the Server protocol stack. Since there can be variances (TLS, client
> > certificate requirements), it seems like a worthwhile addition to enable
> > deeper analysis or logging.
> >
> >
> >> On Tue, Jul 7, 2020 at 10:56 PM Sudheer Vinukonda
> >> <su...@yahoo.com.invalid> wrote:
> >>
> >>
> >>
> >>
> >>>> 1. Add TSHttpTxnServerProtocolStackGet and
> >> TSHttpTxnServerProtocolStackContains. These are the server-side
> >> analogues to the already existing client-side functions.
> >>
> >> Hmm...not sure if we should be adding these API - AFAIK, we still don't
> >> really support customizing the Server protocol stack the way we do
> Client's
> >> using proxy.config.http.server_ports ("
> >>
> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html#proxy-config-http-server-ports
> >> ").
> >>
> >> - Sudheer
> >>
> >> On Tuesday, July 7, 2020, 07:52:34 PM PDT, Brian Neradt <
> >> brian.neradt@gmail.com> wrote:
> >>
> >> Hi dev@trafficserver.apache.org,
> >>
> >> This is for a TS API update review.
> >>
> >> To support some Traffic Dump features, I'd like to update the TS API in
> the
> >> following ways:
> >>
> >> 1. Add TSHttpTxnServerProtocolStackGet
> >> and TSHttpTxnServerProtocolStackContains. These are the server-side
> >> analogues to the already existing client-side functions.
> >> 2. TSHttpTxnServerVConnGet: This is a TSHttpTxn version of the already
> >> existing TSHttpSsnServerVConnGet. This allows a user to get the
> >> server-side NetVconnection from a transaction.
> >> 3. TSVConnProvidedSslCert: This builds off of Susan's PR
> >> https://github.com/apache/trafficserver/pull/6699 by exposing a method
> >> to query whether a TLS cert was provided to the peer on the virtual
> >> connection.
> >>
> >> The following Traffic Dump PR has these updates:
> >> https://github.com/apache/trafficserver/pull/6972
> >>
> >> Note the PR contains doc updates describing each of these functions. See
> >> the first three files listed in the files section of the PR:
> >> https://github.com/apache/trafficserver/pull/6972/files
> >>
> >> Please let me know if there are any concerns or suggestions for
> improvement
> >> concerning this.
> >>
> >> Thanks,
> >> 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
> >>
>
>
--
"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
Re: New TS APIs: server side protocol stack and client cert information
Posted by Brian Neradt <br...@gmail.com>.
Is there another way for Traffic Dump to know what the protocol stack is on
the server side on a per transaction basis? Without this server-side API,
it seems it would not be easy for Traffic Dump or any plugin to get this
information. It is being added to satisfy a need Traffic Dump has. As you
point out, it adds something of a symmetry that already exists as a
precedent on the client side.
Thank you for your thoughts.
Brian
On Wed, Jul 8, 2020 at 10:28 AM Sudheer Vinukonda
<su...@yahoo.com.invalid> wrote:
> Right, I understand that. But, the server side protocol stack isn’t as
> varied or has anywhere as many combinations as the client side and is
> largely determined by system wide setting on the ATS side, no? I suppose it
> may add some sort of symmetry, but I wonder if it somehow feels
> superfluous.
>
> > On Jul 8, 2020, at 8:12 AM, Susan Hinrichs <sh...@verizonmedia.com.invalid>
> wrote:
> >
> > The TSHttpTxnServerProtocolStackGet and
> > TSHttpTxnServerProtocolStackContains are read only. They do not
> customize
> > the Server protocol stack, but they give the plugin the ability to
> analyze
> > the Server protocol stack. Since there can be variances (TLS, client
> > certificate requirements), it seems like a worthwhile addition to enable
> > deeper analysis or logging.
> >
> >
> >> On Tue, Jul 7, 2020 at 10:56 PM Sudheer Vinukonda
> >> <su...@yahoo.com.invalid> wrote:
> >>
> >>
> >>
> >>
> >>>> 1. Add TSHttpTxnServerProtocolStackGet and
> >> TSHttpTxnServerProtocolStackContains. These are the server-side
> >> analogues to the already existing client-side functions.
> >>
> >> Hmm...not sure if we should be adding these API - AFAIK, we still don't
> >> really support customizing the Server protocol stack the way we do
> Client's
> >> using proxy.config.http.server_ports ("
> >>
> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html#proxy-config-http-server-ports
> >> ").
> >>
> >> - Sudheer
> >>
> >> On Tuesday, July 7, 2020, 07:52:34 PM PDT, Brian Neradt <
> >> brian.neradt@gmail.com> wrote:
> >>
> >> Hi dev@trafficserver.apache.org,
> >>
> >> This is for a TS API update review.
> >>
> >> To support some Traffic Dump features, I'd like to update the TS API in
> the
> >> following ways:
> >>
> >> 1. Add TSHttpTxnServerProtocolStackGet
> >> and TSHttpTxnServerProtocolStackContains. These are the server-side
> >> analogues to the already existing client-side functions.
> >> 2. TSHttpTxnServerVConnGet: This is a TSHttpTxn version of the already
> >> existing TSHttpSsnServerVConnGet. This allows a user to get the
> >> server-side NetVconnection from a transaction.
> >> 3. TSVConnProvidedSslCert: This builds off of Susan's PR
> >> https://github.com/apache/trafficserver/pull/6699 by exposing a method
> >> to query whether a TLS cert was provided to the peer on the virtual
> >> connection.
> >>
> >> The following Traffic Dump PR has these updates:
> >> https://github.com/apache/trafficserver/pull/6972
> >>
> >> Note the PR contains doc updates describing each of these functions. See
> >> the first three files listed in the files section of the PR:
> >> https://github.com/apache/trafficserver/pull/6972/files
> >>
> >> Please let me know if there are any concerns or suggestions for
> improvement
> >> concerning this.
> >>
> >> Thanks,
> >> 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
> >>
>
>
--
"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
Re: New TS APIs: server side protocol stack and client cert information
Posted by Sudheer Vinukonda <su...@yahoo.com.INVALID>.
Right, I understand that. But, the server side protocol stack isn’t as varied or has anywhere as many combinations as the client side and is largely determined by system wide setting on the ATS side, no? I suppose it may add some sort of symmetry, but I wonder if it somehow feels superfluous.
> On Jul 8, 2020, at 8:12 AM, Susan Hinrichs <sh...@verizonmedia.com.invalid> wrote:
>
> The TSHttpTxnServerProtocolStackGet and
> TSHttpTxnServerProtocolStackContains are read only. They do not customize
> the Server protocol stack, but they give the plugin the ability to analyze
> the Server protocol stack. Since there can be variances (TLS, client
> certificate requirements), it seems like a worthwhile addition to enable
> deeper analysis or logging.
>
>
>> On Tue, Jul 7, 2020 at 10:56 PM Sudheer Vinukonda
>> <su...@yahoo.com.invalid> wrote:
>>
>>
>>
>>
>>>> 1. Add TSHttpTxnServerProtocolStackGet and
>> TSHttpTxnServerProtocolStackContains. These are the server-side
>> analogues to the already existing client-side functions.
>>
>> Hmm...not sure if we should be adding these API - AFAIK, we still don't
>> really support customizing the Server protocol stack the way we do Client's
>> using proxy.config.http.server_ports ("
>> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html#proxy-config-http-server-ports
>> ").
>>
>> - Sudheer
>>
>> On Tuesday, July 7, 2020, 07:52:34 PM PDT, Brian Neradt <
>> brian.neradt@gmail.com> wrote:
>>
>> Hi dev@trafficserver.apache.org,
>>
>> This is for a TS API update review.
>>
>> To support some Traffic Dump features, I'd like to update the TS API in the
>> following ways:
>>
>> 1. Add TSHttpTxnServerProtocolStackGet
>> and TSHttpTxnServerProtocolStackContains. These are the server-side
>> analogues to the already existing client-side functions.
>> 2. TSHttpTxnServerVConnGet: This is a TSHttpTxn version of the already
>> existing TSHttpSsnServerVConnGet. This allows a user to get the
>> server-side NetVconnection from a transaction.
>> 3. TSVConnProvidedSslCert: This builds off of Susan's PR
>> https://github.com/apache/trafficserver/pull/6699 by exposing a method
>> to query whether a TLS cert was provided to the peer on the virtual
>> connection.
>>
>> The following Traffic Dump PR has these updates:
>> https://github.com/apache/trafficserver/pull/6972
>>
>> Note the PR contains doc updates describing each of these functions. See
>> the first three files listed in the files section of the PR:
>> https://github.com/apache/trafficserver/pull/6972/files
>>
>> Please let me know if there are any concerns or suggestions for improvement
>> concerning this.
>>
>> Thanks,
>> 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
>>
Re: New TS APIs: server side protocol stack and client cert information
Posted by Susan Hinrichs <sh...@verizonmedia.com.INVALID>.
The TSHttpTxnServerProtocolStackGet and
TSHttpTxnServerProtocolStackContains are read only. They do not customize
the Server protocol stack, but they give the plugin the ability to analyze
the Server protocol stack. Since there can be variances (TLS, client
certificate requirements), it seems like a worthwhile addition to enable
deeper analysis or logging.
On Tue, Jul 7, 2020 at 10:56 PM Sudheer Vinukonda
<su...@yahoo.com.invalid> wrote:
>
>
>
> >> 1. Add TSHttpTxnServerProtocolStackGet and
> TSHttpTxnServerProtocolStackContains. These are the server-side
> analogues to the already existing client-side functions.
>
> Hmm...not sure if we should be adding these API - AFAIK, we still don't
> really support customizing the Server protocol stack the way we do Client's
> using proxy.config.http.server_ports ("
> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html#proxy-config-http-server-ports
> ").
>
> - Sudheer
>
> On Tuesday, July 7, 2020, 07:52:34 PM PDT, Brian Neradt <
> brian.neradt@gmail.com> wrote:
>
> Hi dev@trafficserver.apache.org,
>
> This is for a TS API update review.
>
> To support some Traffic Dump features, I'd like to update the TS API in the
> following ways:
>
> 1. Add TSHttpTxnServerProtocolStackGet
> and TSHttpTxnServerProtocolStackContains. These are the server-side
> analogues to the already existing client-side functions.
> 2. TSHttpTxnServerVConnGet: This is a TSHttpTxn version of the already
> existing TSHttpSsnServerVConnGet. This allows a user to get the
> server-side NetVconnection from a transaction.
> 3. TSVConnProvidedSslCert: This builds off of Susan's PR
> https://github.com/apache/trafficserver/pull/6699 by exposing a method
> to query whether a TLS cert was provided to the peer on the virtual
> connection.
>
> The following Traffic Dump PR has these updates:
> https://github.com/apache/trafficserver/pull/6972
>
> Note the PR contains doc updates describing each of these functions. See
> the first three files listed in the files section of the PR:
> https://github.com/apache/trafficserver/pull/6972/files
>
> Please let me know if there are any concerns or suggestions for improvement
> concerning this.
>
> Thanks,
> 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
>
Re: New TS APIs: server side protocol stack and client cert
information
Posted by Sudheer Vinukonda <su...@yahoo.com.INVALID>.
>> 1. Add TSHttpTxnServerProtocolStackGet and TSHttpTxnServerProtocolStackContains. These are the server-side
analogues to the already existing client-side functions.
Hmm...not sure if we should be adding these API - AFAIK, we still don't really support customizing the Server protocol stack the way we do Client's using proxy.config.http.server_ports ("https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html#proxy-config-http-server-ports").
- Sudheer
On Tuesday, July 7, 2020, 07:52:34 PM PDT, Brian Neradt <br...@gmail.com> wrote:
Hi dev@trafficserver.apache.org,
This is for a TS API update review.
To support some Traffic Dump features, I'd like to update the TS API in the
following ways:
1. Add TSHttpTxnServerProtocolStackGet
and TSHttpTxnServerProtocolStackContains. These are the server-side
analogues to the already existing client-side functions.
2. TSHttpTxnServerVConnGet: This is a TSHttpTxn version of the already
existing TSHttpSsnServerVConnGet. This allows a user to get the
server-side NetVconnection from a transaction.
3. TSVConnProvidedSslCert: This builds off of Susan's PR
https://github.com/apache/trafficserver/pull/6699 by exposing a method
to query whether a TLS cert was provided to the peer on the virtual
connection.
The following Traffic Dump PR has these updates:
https://github.com/apache/trafficserver/pull/6972
Note the PR contains doc updates describing each of these functions. See
the first three files listed in the files section of the PR:
https://github.com/apache/trafficserver/pull/6972/files
Please let me know if there are any concerns or suggestions for improvement
concerning this.
Thanks,
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