I'm ok with returning TSError in the case that the requested protocol makes
no sense.
The original argument for returning TSSuccess was that the plugin didn't
need to do additional argument checks. But I can see the argument that it
would be nice to know whether the protocol enable/disable actual
I agree with Sudheer. There should be no difference between UnixNetVC and
SSLNetVC when calling the API with "H3" as the protocol name (H3 is only
available on QUICNetVC).
Masakazu
On Tue, Aug 6, 2019 at 8:52 AM Sudheer Vinukonda
wrote:
> Sounds reasonable to me, except I wonder if it’d make mo
Sounds reasonable to me, except I wonder if it’d make more sense for the API to
return TSError on a UnixNetVC, instead of silently returning TSSuccess.
>>> If the TSVConn is a UnixNetVC, the functions will do nothing and return
success.
> On Aug 5, 2019, at 12:46 PM, Susan Hinrichs
> wrote:
>
The TSProtoSet functions (
https://docs.trafficserver.apache.org/en/latest/developer-guide/api/functions/TSProtoSet.en.html)
were created for tls_proto, our early plugin to disable HTTP/2 on a per
connection basis. Since then, this HTTP/2 disable logic has been absorbed
into the core via the sni.y
