You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Leif Hedstrom <zw...@apache.org> on 2024/09/19 20:32:50 UTC
Is anyone using the internal header @WWW-Auth ?
While poking around mime headers, I noticed we have a special case around this internal header, @WWW-Auth. If set, it seems it can force cached content to be reauthenticated on every request. This is handled by setting the t_state.www_auth_content when this header is there.
Now, there’s nothing in ATS that actually sets @WWW-Auth, you would have to do that via a plugin (it’s an internal header, so can not come from origin either I’m pretty sure?). I feel that this may be a legacy of some old feature that we no longer support. I’m thinking we should remove this special code around this head, and if needed, we can add an API around the t_state.www_auth_content instead?
I also suspect that there are other ways we today can do to force authentication for content, such as the auth_proxy plugin. Removing this header, removes a couple of lookups on this header, neither of which can be accelerated today via the WKS handling.
Thoughts? If you are using this header, for this use case, please let us know. It’s not documented anywhere either.
— Leif
Re: Is anyone using the internal header @WWW-Auth ?
Posted by Leif Hedstrom <zw...@apache.org>.
Forgot about this, and there was no replies, so I’d like to remove this @WWW-auth (internal only) header from ATS v11.0.
— Leif
> On Sep 19, 2024, at 2:32 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> While poking around mime headers, I noticed we have a special case around this internal header, @WWW-Auth. If set, it seems it can force cached content to be reauthenticated on every request. This is handled by setting the t_state.www_auth_content when this header is there.
>
> Now, there’s nothing in ATS that actually sets @WWW-Auth, you would have to do that via a plugin (it’s an internal header, so can not come from origin either I’m pretty sure?). I feel that this may be a legacy of some old feature that we no longer support. I’m thinking we should remove this special code around this head, and if needed, we can add an API around the t_state.www_auth_content instead?
>
> I also suspect that there are other ways we today can do to force authentication for content, such as the auth_proxy plugin. Removing this header, removes a couple of lookups on this header, neither of which can be accelerated today via the WKS handling.
>
> Thoughts? If you are using this header, for this use case, please let us know. It’s not documented anywhere either.
>
> — Leif
>
Re: Is anyone using the internal header @WWW-Auth ?
Posted by Leif Hedstrom <zw...@apache.org>.
Forgot about this, and there was no replies, so I’d like to remove this @WWW-auth (internal only) header from ATS v11.0.
— Leif
> On Sep 19, 2024, at 2:32 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> While poking around mime headers, I noticed we have a special case around this internal header, @WWW-Auth. If set, it seems it can force cached content to be reauthenticated on every request. This is handled by setting the t_state.www_auth_content when this header is there.
>
> Now, there’s nothing in ATS that actually sets @WWW-Auth, you would have to do that via a plugin (it’s an internal header, so can not come from origin either I’m pretty sure?). I feel that this may be a legacy of some old feature that we no longer support. I’m thinking we should remove this special code around this head, and if needed, we can add an API around the t_state.www_auth_content instead?
>
> I also suspect that there are other ways we today can do to force authentication for content, such as the auth_proxy plugin. Removing this header, removes a couple of lookups on this header, neither of which can be accelerated today via the WKS handling.
>
> Thoughts? If you are using this header, for this use case, please let us know. It’s not documented anywhere either.
>
> — Leif
>