Apigee is returning “connection: close”, when the user agent string contains “MSIE 6.0”

Google Cloud Apigee
1

Request with User-Agent header value containing MSIE 6.0 and response is having connection: close

POST https://test.solutions/ConfigurationManager.asmx HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 4.0.30319.42000)
Content-Type: text/xml; charset=utf-8
SOAPAction: “GetApplicationManagerConfig”
Host: test.solutions

<?xml version="1.0" encoding="utf-8"?>

HTTP/1.1 503 Service Unavailable
Date: Thu, 06 Jul 2023 19:47:41 GMT
Content-Type: application/json
Content-Length: 279
Connection: close

{“Envelope”:{“encodingStyle”:“http://schemas.xmlsoap.org/soap/encoding/”,“Body”:{“Fault”:{“faultcode”:“soap:Server”,“faultstring”:“The Service is temporarily unavailable”,“faultactor”:{},“detail”:{“source”:{“errorcode”:“messaging.adaptors.http.flow.ServiceUnavailable”}}}}}}

Request without the User-Agent value and response is having connection: keep-alive
Also, Request without the most recent browser User-Agent value and response is having connection: keep-alive

POST https://test.solutions/ConfigurationManager.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: “GetApplicationManagerConfig”
Host: test.solutions

<?xml version="1.0" encoding="utf-8"?>

HTTP/1.1 503 Service Unavailable
Date: Thu, 06 Jul 2023 19:47:41 GMT
Content-Type: application/json
Content-Length: 279
Connection: keep-alive

{“Envelope”:{“encodingStyle”:“http://schemas.xmlsoap.org/soap/encoding/”,“Body”:{“Fault”:{“faultcode”:“soap:Server”,“faultstring”:“The Service is temporarily unavailable”,“faultactor”:{},“detail”:{“source”:{“errorcode”:“messaging.adaptors.http.flow.ServiceUnavailable”}}}}}}

Have anyone noticed this behavior and knows the reason why Apigee Edge v4.51 is returning “connection: close” in the response http header when the user-agent string of HTTP request header contains “MSIE 6.0” ?

By changing it to different value or by removing it, Apigee returns response with “Connection: keep-alive”.

Also, What are all the User-Agent values Apigee 45.1 OPDK supports? Are there any ways to ignore the user-agent value or change the behavior to return Connection: keep-alive for user-agent string containing “MSIE 6.0”.

2

I am unsure but it is not apigee behaviour & more of a backend error? possible? May be speak to your colleagues who manages backend system to not to close the connections with such header.

As a simple exercise do a simple test just creating a dummy proxy and provide the user-agent header which is causing the issue to isolate..I am not to replicate it but I am not using the OPDK at the moment.

  1. Looking at the error either your backend is overloaded/maintainence/some issues from backend - The Service is temporarily unavailable

  2. check https://docs.apigee.com/api-platform/reference/endpoint-properties-reference request.retain.headers or request.retain.headers.enabled option & decide which headers you want to propagate to backend.

what you provided looks like In your case, the server is closing the connection because the User-Agent header indicates that the client is using Internet Explorer 6.0. Internet Explorer 6.0 is a very old browser that is no longer supported by Microsoft.

3

There is nothing to do with the backend endpoint connection or backend service related issue. Same behavior exists for apigee response with HTTP 200 OK from the backend service. Also, I am not trying to pass the user-agent string to the backend service endpoint.

In this case, Server is being Apigee returning response to calling application with “connection: close” in the response HTTP header when it receives this specific User-Agent string in the request HTTP header (i.e. User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 4.0.30319.42000)).

4

@dchiesa1 Have you seen this behavior?

"connection: keep-alive or “connection: close” is returned by apigee based upon the user-agent value.

I discovered that when request comes to apigee with user-agent value (“Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 4.0.30319.42000)”) containing “MSIE 6.0”, apigee replies with “Connection:close” in the response HTTP header.
When request comes without User-Agent value or with different user-agent value then apigee replies with “connection: keep-alive” in the response HTTP header.
See below two examples.

I am expecting Apigee to return “connection: keep-alive” so question is why Apigee is returning “connection: close” when the user agent string contains “MSIE 6.0”? What are all the User-Agent values Apigee Edge/OPDK 4.51 supports?

Request with User-Agent header value containing MSIE 6.0 and response is having connection: close

POST https://test.solutions/ConfigurationManager.asmx HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 4.0.30319.42000)
Content-Type: text/xml; charset=utf-8
SOAPAction: “GetApplicationManagerConfig”
Host: test.solutions

<?xml version="1.0" encoding="utf-8"?>

HTTP/1.1 200 OK
Date: Thu, 06 Jul 2023 19:47:41 GMT
Content-Type: application/json
Content-Length: 290
Connection: Close

… payload …

Request without the User-Agent value and response is having connection: keep-alive
Also, Request without the most recent browser User-Agent value and response is having connection: keep-alive

POST https://test.solutions/ConfigurationManager.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: “GetApplicationManagerConfig”
Host: test.solutions

<?xml version="1.0" encoding="utf-8"?>

HTTP/1.1 200 OK
Date: Thu, 06 Jul 2023 19:47:41 GMT
Content-Type: application/json
Content-Length: 279
Connection: keep-alive

… payload …

5

Unable to replicate it in 4.51 OPDK. More over did u read my earlier post and test it /cleanse the headers propagation if it is not required. Can you direct message message & would like to see the complete flow in action if possible?

6

The only clue I found by Googling is that VMWare NSX will purposefully send a connection:close to MSIE 6.0, because of “a known issue” with MSIE 6.0 browsers. The article does not cite the issue. I had no luck tracking that issue down. You could try asking VMWare for a reference.

Is it possible that either VMWare NSX is the upstream for your Apigee proxy, and the VMWare gateway is sending the connection:close? or is it possible there is some other load balancer doing similar because of “the known issue”?

But anyway, your question seems like a snipe hunt, if you don’t mind my saying so. MSIE 6.0 implies Internet Explorer 6.0. Wikipedia says it was first released in 2001, and last updated in 2008. Major platforms began deprecating it in 2009 and 2010. Microsoft ended all support in 2016, even for extended support customers. Whatever client is sending that header, is out of date and needs to be replaced, or is wrong or faking. Given all that, I think this question is not worth any further expenditure of time.

7

Thank you @API-Evangelist and @dchiesa1 for looking into this.

*) The issue is resolved by removing the User-agent HTTP header variable from the calling application POST call. Actually, Call is getting initiated from application server and not from the browser so it was safe to remove the user-agent header.

*) As per Apigee support, behavior can be changed to allow keep-alive for MSIE 6.0 by setting “keepalive_disable none” in nginx.conf file of edge-router. Implementing the “keepalive_disable none” will make apigee respond with “connection:keep-alive” for all the browsers and not just MSIE 6.0. Bypassing the browser checking introduces security vulnerability of Man in the middle attack and so we did not go with this approach.

1 Like
8

I’m glad you sorted it out. Seems like the App Server is faking, with that user-agent header containing MSIE 6.0. It shouldn’t be doing that. That is a misrepresentation. But this is just, like, my opinion man.