@Leif,
Yes, this is for certificated loaded via plugin. I don't know of any such API
to hand a new context to ATS. Again, looking at the code, the ocsp is enabled
on a context only at the initialization phase. So any context created
externally in a plugin does not get configured with the global
That's a bit much. Let me take a look at how it could be refactored to
reduce the dependencies.
On Tue, Mar 27, 2018 at 6:02 PM, Leif Hedstrom wrote:
>
>
> > On Mar 27, 2018, at 4:54 PM, Walt Karas wrote:
> >
> > Is there any ways to ensure ABI compatibility other than to compile
> > the plugin
Peter,
There is a memory leak when reloading parent.config and if I remember correctly,
you use it. If you’re updating parent.config quite a bit, you might try cherry
picking
this commit 180504915d8f1f1121c8f6361896c324f7e2431d
John
> On Mar 27, 2018, at 12:40 PM, Alan Carroll
> wrote:
>
>
> On Mar 27, 2018, at 4:54 PM, Walt Karas wrote:
>
> Is there any ways to ensure ABI compatibility other than to compile
> the plugin and the core with the same compiler and same options?
Well, we can’t change things such as orders within enum / structs in the core
for an example of an ABI in
Is there any ways to ensure ABI compatibility other than to compile
the plugin and the core with the same compiler and same options?
On Tue, Mar 27, 2018 at 5:51 PM, Leif Hedstrom wrote:
>
>
>> On Mar 27, 2018, at 4:23 PM, Walt Karas wrote:
>>
>> With some tricky symbolic links, I could probably
> On Mar 27, 2018, at 4:23 PM, Walt Karas wrote:
>
> With some tricky symbolic links, I could probably arrive at a solution
> where these header would be exported (to plugins) in include/detail or
> something, not include/ts, so plugins writers would know not to
> include them directly.
It a
> On Mar 27, 2018, at 4:36 PM, Alan Carroll
> wrote:
>
> Persia should correct me if I'm wrong, but my understanding is the default
> is no handling. The ATS core provides a default handler for OCSP and the
> point of this call is to set this context to use the ATS core default OCSP
> handler.
Persia should correct me if I'm wrong, but my understanding is the default
is no handling. The ATS core provides a default handler for OCSP and the
point of this call is to set this context to use the ATS core default OCSP
handler. That is how this makes OCSP easier for plugins - rather than
writin
> On Mar 27, 2018, at 1:52 PM, Alan Carroll
> wrote:
>
> Chatting with Persia privately, I recommend changing the name to something
> like `TSSslOCSPDefaultHandlingEnable`, which is what it really does
> (enable, for that context, the default / core OCSP handling).
I'm confused ... isn't the
With some tricky symbolic links, I could probably arrive at a solution
where these header would be exported (to plugins) in include/detail or
something, not include/ts, so plugins writers would know not to
include them directly.
On Tue, Mar 27, 2018 at 5:15 PM, Derek Dagit wrote:
> One reason thi
One reason this could be scary is that should we change any of these
headers going forward, it could mean a backward-incompatible release for
ATS.
In-place upgrades may not be possible for administrators without
recompiling their plugins.
On Tue, Mar 27, 2018 at 5:08 PM, Walt Karas wrote:
> If
If we make BufferWriter.h available to C++ plugins, we would also have
to make all of these header files available to plugins:
MemSpan.h
ink_assert.h
BufferWriterForward.h
ink_apidefs.h
ink_error.h
ink_std_compat.h
ink_platform.h
ink_config.h
ink_autoconf.h
Scary right? Or not so much?
Hi,
Are the traffic stats persistent? I am using 'traffic_ctl metric get/match'
commands to query the statistics. Even after restarting, the numbers do not
change. Tried the following...
./traffic_ctl metric clear
./traffic_ctl metric zero
These did not help either. Trying to debug some weird is
Chatting with Persia privately, I recommend changing the name to something
like `TSSslOCSPDefaultHandlingEnable`, which is what it really does
(enable, for that context, the default / core OCSP handling).
On Tue, Mar 27, 2018 at 3:23 PM, Persia Aziz
wrote:
>
> @Kit,
> Sure. I will provide an exa
@Kit,
Sure. I will provide an example plugin.
Syeda Persia Aziz
Software DeveloperYahoo! Inc.Champaign, Illinois
On Tuesday, March 27, 2018, 3:08:31 PM CDT, Shu Kit Chan
wrote:
And it would be of great help if we can have a example plugin to
illustrate hot this can be used.
Thanks.
And it would be of great help if we can have a example plugin to
illustrate hot this can be used.
Thanks.
Kit
On Tue, Mar 27, 2018 at 1:06 PM, Alan Carroll
wrote:
> I made some comments on the PR. I would recommend at a minimum having a
> reference / link over to where the OCSP callback is desc
I made some comments on the PR. I would recommend at a minimum having a
reference / link over to where the OCSP callback is described.
On Tue, Mar 27, 2018 at 3:04 PM, Persia Aziz
wrote:
> This API will be used for contexts created in the plugin. Since we already
> have the OCSP query,response a
This API will be used for contexts created in the plugin. Since we already have
the OCSP query,response and caching mechanism are already in ATS, the developer
can choose to use this callback for OCSP stapling. Otherwise the whole OCSP
part has to rewritten in the plugin. We have a use case wher
> On Mar 27, 2018, at 12:45 PM, Persia Aziz
> wrote:
>
> TSReturnCode TSSslOCSPCallbackSet(TSSslContext ctx)
> TSSslOCSPCallbackSet sets the OCSP callback described in ATS
What does "sets the OCSP callback described in ATS" mean? If I'm writing a
plugin why would I call this API?
> to the S
TSReturnCode TSSslOCSPCallbackSet(TSSslContext ctx)
TSSslOCSPCallbackSet sets the OCSP callback described in ATS
to the SSL context passed as an argument. This API is useful for contexts
created externally via plugin
PR: https://github.com/apache/trafficserver/pull/3353/files
Syeda Persia Aziz
S
Our experience at Oath is that 7.1.2 is much improved.
On Tue, Mar 27, 2018 at 1:13 PM, Chou, Peter wrote:
> Thanks for the responses. We will probably wait until we move to the next
> release of ATS (7.1.x) to re-evaluate this to see if there is any
> improvement.
>
> -Original Message-
Thanks for the responses. We will probably wait until we move to the next
release of ATS (7.1.x) to re-evaluate this to see if there is any improvement.
-Original Message-
From: Alan Carroll [mailto:solidwallofc...@oath.com.INVALID]
Sent: Monday, March 19, 2018 2:53 PM
To: dev@trafficser
22 matches
Mail list logo