[
https://issues.apache.org/jira/browse/TS-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15143670#comment-15143670
]
Aaron McClimont edited comment on TS-3866 at 2/11/16 11:09 PM:
---------------------------------------------------------------
Reverting the following logic in version 4.2.3 back to what existed for 4.1.2
resolves the issue... but with unknown repercussions:
{code:title=trafficserver-4.2.3/proxy/http/HttpSM_4.2.3.diff}
2944,2950c2944,2952
< // If the option to attach the server session to the client session is set
< // and if the client is still around and the client is keep-alive, attach
the
< // server session to so the next ka request can use it. Server sessions
will
< // be placed into the shared pool if the next incoming request is for a
different
< // origin server
< if (t_state.http_config_param->attach_server_session_to_client == 1 &&
< ua_session && t_state.client_info.keep_alive == HTTP_KEEPALIVE) {
---
> // If the client is still around, attach the server session
> // to so the next ka request can use it. We bind privately to the
> // client to add some degree of affinity to the system. However,
> // we turn off private binding when outbound connections are being
> // limit since it makes it too expensive to initiate a purge of idle
> // server keep-alive sessions
> if (ua_session && t_state.client_info.keep_alive == HTTP_KEEPALIVE &&
> t_state.http_config_param->server_max_connections <= 0 &&
> t_state.txn_conf->origin_max_connections <= 0) {
{code}
Note: Same patch as for 4.2.0, lines are only offset by -3.
patch applied as follows:
{code}
cd trafficserver-4.2.3/proxy/http
patch HttpSM.cc < HttpSM_4.2.3.diff
{code}
was (Author: a_mcclimont):
Reverting the following logic in version 4.2.3 back to what existed for 4.1.2
resolves the issue... but with unknown repercussions:
{code:title=trafficserver-4.2.3/proxy/http/HttpSM_4.2.3.diff}
2944,2950c2944,2952
< // If the option to attach the server session to the client session is set
< // and if the client is still around and the client is keep-alive, attach
the
< // server session to so the next ka request can use it. Server sessions
will
< // be placed into the shared pool if the next incoming request is for a
different
< // origin server
< if (t_state.http_config_param->attach_server_session_to_client == 1 &&
< ua_session && t_state.client_info.keep_alive == HTTP_KEEPALIVE) {
---
> // If the client is still around, attach the server session
> // to so the next ka request can use it. We bind privately to the
> // client to add some degree of affinity to the system. However,
> // we turn off private binding when outbound connections are being
> // limit since it makes it too expensive to initiate a purge of idle
> // server keep-alive sessions
> if (ua_session && t_state.client_info.keep_alive == HTTP_KEEPALIVE &&
> t_state.http_config_param->server_max_connections <= 0 &&
> t_state.txn_conf->origin_max_connections <= 0) {
{code}
Note: Same patch, lines are only offset by -3.
patch applied as follows:
{code}
cd trafficserver-4.2.3/proxy/http
patch HttpSM.cc < HttpSM_4.2.3.diff
{code}
> Browser always prompts for authentication (NTLM) - Regression?
> --------------------------------------------------------------
>
> Key: TS-3866
> URL: https://issues.apache.org/jira/browse/TS-3866
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Affects Versions: 5.3.0, 5.3.1
> Environment: RHEL 6.5 64-bit
> Reporter: Aaron McClimont
> Priority: Critical
> Labels: Regression
> Fix For: 6.2.0
>
> Attachments: HttpSM_4.2.0.diff, HttpSM_4.2.3.diff
>
>
> NTLM authentication through Apache TrafficServer version 5.3.1 appears to be
> broken, with the authentication prompt being displayed repeatedly.
> Version 4.1.2 (using the same configuration files) works successfully.
> Notes:
> * HTTPS does not resolve the issue in version 5.3.1 like it does with version
> 4.1.2
> * proxy.config.http.share_server_sessions is set to 0 (default: 2)
> * proxy.config.http.auth_server_session_private is set to 1
> This issue appears to be related to TS-1491 identified in the 3.2 releases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
