ATS proxy closes the connection "close" even if client sends "keep-alive"

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

ATS proxy closes the connection "close" even if client sends "keep-alive"

Ananth Laxminarasimhan (alaxmina)

I have configured ATS as a web proxy in a NTLM authentication domain; and, have a plugin with a function for TS_HTTP_READ_REQUEST_HDR_HOOK say, func_1.

In func_1 which is invoked during the request header, I create a hook for TS_HTTP_SEND_RESPONSE_HDR_HOOK (say, func_2) and then do a TSHttpTxnReenable(txnp, TS_EVENT_HTTP_ERROR);

 

Subsequently, when func_2 is invoked during the SEND_RESPONSE_HEADER event, I frame a “407 Proxy Auth required” response header along with Proxy-Authenticate set to “NTLM” and then do a TSHttpTxnReenable(txnp, TS_EVENT_HTTP_CONTINUE);

 

Func_1() {

….

TSHttpTxnHookAdd(txnp, TS_HTTP_SEND_RESPONSE_HDR_HOOK,

                                 TSContCreate(responseHook, TS_NULL_MUTEX));

            }

            TSHttpTxnReenable(txnp, TS_EVENT_HTTP_ERROR);

….

return;

}

 

func_2() {

 

TSHttpTxnReenable(txnp, TS_EVENT_HTTP_CONTINUE);

return;

}

 

What happens is that even though the client sends a “Connection: keep-alive”, ATS seems to be returning a “Connection: close” which results in the connection getting closed.

 

 

> GET http://www.purple.com/ HTTP/1.1

> Host: www.purple.com

> Proxy-Authorization: NTLM TlRMTVNTUAABAAAABoIIAAAAAAAAAAAAAAAAAAAAAAA=

> User-Agent: curl/7.44.0

> Accept: */*

> Proxy-Connection: Keep-Alive

>

< HTTP/1.1 407 Proxy Authentication Required

< Date: Sun, 03 Sep 2017 10:47:24 GMT

< Connection: close

< Via: http/1.1 POD128-CentOS7-01 (ApacheTrafficServer/6.2.1)

< Server: ATS/6.2.1

< Proxy-Authenticate: NTLM

< Content-Length: 15

< Content-Type: text/plain

<

  0    15    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0

* Closing connection 7

 

Why is ATS closing the connection?And, how can I control this behavior?

 

Thanks,

Ananth

Reply | Threaded
Open this post in threaded view
|

Re: ATS proxy closes the connection "close" even if client sends "keep-alive"

Reindl Harald


Am 03.09.2017 um 15:28 schrieb Ananth Laxminarasimhan (alaxmina):
> What happens is that even though the client sends a “Connection:
> keep-alive”, ATS seems to be returning a “Connection: close” which
> results in the connection getting closed

keep-alöive is finally a descision of the server and not the client, as
well as how long the server waits and after how much keep-alive requests
it closes the connection anyways

[root@proxy:~]$ cat records.config | grep keep
CONFIG proxy.config.http.keep_alive_enabled_in INT 1
CONFIG proxy.config.http.keep_alive_enabled_out INT 1
CONFIG proxy.config.http.origin_min_keep_alive_connections INT 1
CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 5
CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 1
Reply | Threaded
Open this post in threaded view
|

Re: ATS proxy closes the connection "close" even if client sends "keep-alive"

Ananth Laxminarasimhan (alaxmina)
Hi,
I tried setting keep proxy.config.http.keep_alive_enabled_in and proxy.config.http.keep_alive_enabled_in  to 1; but, that didn’t help.

I was looking at the following issue in ATS JIIRA site:
https://issues.apache.org/jira/browse/TS-3866 - Browser always prompts for authentication (NTLM) - Regression

I am using 6.2.1; I tried applying the patch, but it doesn’t seem to work.

Any suggestions?

Thanks,
ANanth


On 03/09/17 9:28 pm, "Reindl Harald" <[hidden email]> wrote:

   
   
    Am 03.09.2017 um 15:28 schrieb Ananth Laxminarasimhan (alaxmina):
    > What happens is that even though the client sends a “Connection:
    > keep-alive”, ATS seems to be returning a “Connection: close” which
    > results in the connection getting closed
   
    keep-alöive is finally a descision of the server and not the client, as
    well as how long the server waits and after how much keep-alive requests
    it closes the connection anyways
   
    [root@proxy:~]$ cat records.config | grep keep
    CONFIG proxy.config.http.keep_alive_enabled_in INT 1
    CONFIG proxy.config.http.keep_alive_enabled_out INT 1
    CONFIG proxy.config.http.origin_min_keep_alive_connections INT 1
    CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 5
    CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 1
   

Reply | Threaded
Open this post in threaded view
|

Re: ATS proxy closes the connection "close" even if client sends "keep-alive"

Alan Carroll-2
From your description it's hard to tell what's going on. In particular, is a request made upstream to the origin? Where does the base response to the user agent come from - your plugin or an upstream server?

I note in the response this field:

< Connection: close

which seems to indicate the connection should be closed. I would investigate where that comes from, and whether it is even ATS that is closing the connection. If you're using curl and it sees that field, curl will close the connection.
Reply | Threaded
Open this post in threaded view
|

Re: ATS proxy closes the connection "close" even if client sends "keep-alive"

Ananth Laxminarasimhan (alaxmina)

Hi,

The “GET” request is made from a client to the server via the ATS proxy; the client (curl) specifies the auth. method to be NTLM.

 

> GET http://www.purple.com/ HTTP/1.1

> Host: www.purple.com

> Proxy-Authorization: NTLM TlRMTVNTUAABAAAABoIIAAAAAAAAAAAAAAAAAAAAAAA=

> User-Agent: curl/7.44.0

> Accept: */*

> Proxy-Connection: Keep-Alive

 

 

The base response to this comes from the plugin – not the server.

 

< HTTP/1.1 407 Proxy Authentication Required

< Date: Mon, 04 Sep 2017 11:21:22 GMT

< Connection: close

< Via: http/1.1 POD128-CentOS7-01.ibwsa (ApacheTrafficServer/6.2.1)

< Server: ATS/6.2.1

< Proxy-Authenticate: NTLM TlRMTVNTUAACAAAABAAEADgAAAAGgokC+E2Uox6iJ80AAAAAAAAAAHYAdgA8AAAABgEAAAAAAA9YTUVOAgAIAFgATQBFAE4AAQAcAFAATwBEADEAMgAzADcALQBXAFMAQQAwADAANgAEAAoAaQBiAGwAbgB4AAMAKABwAG8AZAAxADIAMwA3AC0AdwBzAGEAMAAwADYALgBpAGIAbABuAHgABwAIAMIJFvBvJdMBAAAAAA==

< Content-Length: 15

< Content-Type: text/plain

 

However, as part of the response header, the plugin ONLY fills in the “Proxy-authenticate” field – the other fields are under the control of ATS.

You would notice that while the client is requesting the connection to be “kept alive”, the ATS specifies that the connection should be “CLOSED”.

 

Thanks,

Ananth

 

 

 

From: Alan Carroll <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Monday, 4 September 2017 7:36 pm
To: "[hidden email]" <[hidden email]>
Subject: Re: ATS proxy closes the connection "close" even if client sends "keep-alive"

 

From your description it's hard to tell what's going on. In particular, is a request made upstream to the origin? Where does the base response to the user agent come from - your plugin or an upstream server?

I note in the response this field:

< Connection: close

which seems to indicate the connection should be closed. I would investigate where that comes from, and whether it is even ATS that is closing the connection. If you're using curl and it sees that field, curl will close the connection.

Reply | Threaded
Open this post in threaded view
|

Re: ATS proxy closes the connection "close" even if client sends "keep-alive"

Reindl Harald


Am 04.09.2017 um 17:46 schrieb Ananth Laxminarasimhan (alaxmina):

> < HTTP/1.1 407 Proxy Authentication Required
> < Date: Mon, 04 Sep 2017 11:21:22 GMT
> < Connection: close
> < Via: http/1.1 POD128-CentOS7-01.ibwsa (ApacheTrafficServer/6.2.1)
> < Server: ATS/6.2.1
> < Proxy-Authenticate: NTLM
> < Content-Length: 15
>
> However, as part of the response header, the plugin ONLY fills in the
> “Proxy-authenticate” field – the other fields are under the control of ATS.
>
> You would notice that while the client is requesting the connection to
> be “kept alive”, the ATS specifies that the connection should be “CLOSED”

pretty sure error responses are never keep-alive
Reply | Threaded
Open this post in threaded view
|

Re: ATS proxy closes the connection "close" even if client sends "keep-alive"

Ananth Laxminarasimhan (alaxmina)
In reply to this post by Ananth Laxminarasimhan (alaxmina)
Hi,
TS-3866 seems to be still open on ATS 6.2.1; and, the suggested patch too doesn’t seem to work.
Any pointers on this would be welcome.

Thanks,
Ananth

On 04/09/17 4:29 pm, "Ananth Laxminarasimhan (alaxmina)" <[hidden email]> wrote:

    Hi,
    I tried setting keep proxy.config.http.keep_alive_enabled_in and proxy.config.http.keep_alive_enabled_in  to 1; but, that didn’t help.
   
    I was looking at the following issue in ATS JIIRA site:
    https://issues.apache.org/jira/browse/TS-3866 - Browser always prompts for authentication (NTLM) - Regression
   
    I am using 6.2.1; I tried applying the patch, but it doesn’t seem to work.
   
    Any suggestions?
   
    Thanks,
    ANanth
   
   
    On 03/09/17 9:28 pm, "Reindl Harald" <[hidden email]> wrote:
   
       
       
        Am 03.09.2017 um 15:28 schrieb Ananth Laxminarasimhan (alaxmina):
        > What happens is that even though the client sends a “Connection:
        > keep-alive”, ATS seems to be returning a “Connection: close” which
        > results in the connection getting closed
       
        keep-alöive is finally a descision of the server and not the client, as
        well as how long the server waits and after how much keep-alive requests
        it closes the connection anyways
       
        [root@proxy:~]$ cat records.config | grep keep
        CONFIG proxy.config.http.keep_alive_enabled_in INT 1
        CONFIG proxy.config.http.keep_alive_enabled_out INT 1
        CONFIG proxy.config.http.origin_min_keep_alive_connections INT 1
        CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 5
        CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 1
       
   
   

Reply | Threaded
Open this post in threaded view
|

Re: ATS proxy closes the connection "close" even if client sends "keep-alive"

Uri Shachar
On Tuesday, September 5, 2017 11:13 AM Ananth Laxminarasimhan (alaxmina) <[hidden email]> wrote:
   
> Hi,
> TS-3866 seems to be still open on ATS 6.2.1; and, the suggested patch too doesn’t seem to work.
> Any pointers on this would be welcome.

ATS sets the "Connection: close" header + configures the connection to close internally whenever a plugin re-enables with an error.
You need to hook on the SEND_RESPONSE_HDRS hookpoint and:
1) Set the Connection / Proxy-Connection headers as desired (ie - to 'keep-alive')
2) Tell ATS to not close the connection by calling TSHttpTxnCloseAfterResponse(txn, 0)

You may also need to call TSHttpTxnClientKeepaliveSet(txn, 1) -- but I'm not 100% sure this is really required in your use case.

                   Cheers,
                                Uri
Reply | Threaded
Open this post in threaded view
|

Re: ATS proxy closes the connection "close" even if client sends "keep-alive"

Ananth Laxminarasimhan (alaxmina)
Hi Uri,
Thanks for the response.
I tried using TSHttpTxnCloseAfterResponse() as you suggested, but, it still closes the connection.
With regards to your point 1) i.e. set the connection headers/proxy connection headers, is there an API to set the connection to “keep-alive”?

Thanks,
Ananth

On 07/09/17 4:54 am, "Uri Shachar" <[hidden email]> wrote:

    On Tuesday, September 5, 2017 11:13 AM Ananth Laxminarasimhan (alaxmina) <[hidden email]> wrote:
       
    > Hi,
    > TS-3866 seems to be still open on ATS 6.2.1; and, the suggested patch too doesn’t seem to work.
    > Any pointers on this would be welcome.
   
    ATS sets the "Connection: close" header + configures the connection to close internally whenever a plugin re-enables with an error.
    You need to hook on the SEND_RESPONSE_HDRS hookpoint and:
    1) Set the Connection / Proxy-Connection headers as desired (ie - to 'keep-alive')
    2) Tell ATS to not close the connection by calling TSHttpTxnCloseAfterResponse(txn, 0)
   
    You may also need to call TSHttpTxnClientKeepaliveSet(txn, 1) -- but I'm not 100% sure this is really required in your use case.
   
                       Cheers,
                                    Uri