408 request timed out response from proxy

[surekhavuchuru]

Hi ,
I am encountering an issue with two different PCs( Working from developer PC and not from DEV or UAT system, same tomcat application invoking the apigee end point) making requests to the same Apigee proxy endpoint:

https://<host>/v1/data-analytics/products/PII/TWPaletteCockpit?$filter=(ingredient eq '9127501').

One PC receives a 200 response, while the second PC receives a 408 response.

Observations from Apigee Debug Mode are enclosed.
I have attached screen shots of the debug mode also.
Even the debug session info is attached.

In case of 408 , it is not throwing the error from the proxy flow as request is parsed it throws the error.

I am puzzled as to why the same requests yield different responses. Specifically, I would like to understand the cause of the 408 response. Any insights would be greatly appreciated!

Request Header Working extracted from debug mode
accept application/json
accept-charset big5,big5-hkscs,cesu-8,euc-jp,euc-kr,gb18030,gb2312,gbk,ibm-thai,ibm00858,ibm01140,ibm01141,ibm01142,ibm01143,ibm01144,ibm01145,ibm01146,ibm01147,ibm01148,ibm01149,ibm037,ibm1026,ibm1047,ibm273,ibm277,ibm278,ibm280,ibm284,ibm285,ibm290,ibm297,ibm420,ibm424,ibm437,ibm500,ibm775,ibm850,ibm852,ibm855,ibm857,ibm860,ibm861,ibm862,ibm863,ibm864,ibm865,ibm866,ibm868,ibm869,ibm870,ibm871,ibm918,iso-2022-cn,iso-2022-jp,iso-2022-jp-2,iso-2022-kr,iso-8859-1,iso-8859-13,iso-8859-15,iso-8859-16,iso-8859-2,iso-8859-3,iso-8859-4,iso-8859-5,iso-8859-6,iso-8859-7,iso-8859-8,iso-8859-9,jis_x0201,jis_x0212-1990,koi8-r,koi8-u,shift_jis,tis-620,us-ascii,utf-16,utf-16be,utf-16le,utf-32,utf-32be,utf-32le,utf-8,windows-1250,windows-1251,windows-1252,windows-1253,windows-1254,windows-1255,windows-1256,windows-1257,windows-1258,windows-31j,x-big5-hkscs-2001,x-big5-solaris,x-euc-jp-linux,x-euc-tw,x-eucjp-open,x-ibm1006,x-ibm1025,x-ibm1046,x-ibm1097,x-ibm1098,x-ibm1112,x-ibm1122,x-ibm1123,x-ibm1124,x-ibm1129,x-ibm1166,x-ibm1364,x-ibm1381,x-ibm1383,x-ibm29626c,x-ibm300,x-ibm33722,x-ibm737,x-ibm833,x-ibm834,x-ibm856,x-ibm874,x-ibm875,x-ibm921,x-ibm922,x-ibm930,x-ibm933,x-ibm935,x-ibm937,x-ibm939,x-ibm942,x-ibm942c,x-ibm943,x-ibm943c,x-ibm948,x-ibm949,x-ibm949c,x-ibm950,x-ibm964,x-ibm970,x-iscii91,x-iso-2022-cn-cns,x-iso-2022-cn-gb,x-iso-8859-11,x-jis0208,x-jisautodetect,x-johab,x-macarabic,x-maccentraleurope,x-maccroatian,x-maccyrillic,x-macdingbat,x-macgreek,x-machebrew,x-maciceland,x-macroman,x-macromania,x-macsymbol,x-macthai,x-macturkish,x-macukraine,x-ms932_0213,x-ms950-hkscs,x-ms950-hkscs-xp,x-mswin-936,x-pck,x-sjis_0213,x-utf-16le-bom,x-utf-32be-bom,x-utf-32le-bom,x-windows-50220,x-windows-50221,x-windows-874,x-windows-949,x-windows-950,x-windows-iso2022jp
content-type text/plain;charset=ISO-8859-1
host api-gdc.uat.apps.uocp.givaudan.com
user-agent Java/11.0.15
x-api-key ba9LVxXX2nr78k2N4piKF7NtVJsZTcldkCwc457RU6HDUcAs
x-apigee-message-id 2efd0a15-6740-4682-949d-74c89f66966837649
x-apigee-tls-cipher TLS_AES_256_GCM_SHA384
x-apigee-tls-protocol TLSv1.3
x-apigee-tls-server-name api-gdc.uat.apps.uocp.givaudan.com
x-apigee-tracking-id be115a26-0c92-4626-8206-83b2aa8740c1
x-application APOLLO
x-envoy-attempt-count 1
x-envoy-expected-rq-timeout-ms 300000
x-forwarded-for 10.129.2.12
x-forwarded-proto https
x-request-id be115a26-0c92-4626-8206-83b2aa8740c1
x-timestamp 1746025278631

Request Content working
Method GET
URI /v1/data-analytics/products/PII/TWPaletteCockpit?%24filter=%28ingredient%20eq%20%279127501%27%29

Request Header not Working
accept application/json
accept-charset big5,big5-hkscs,cesu-8,euc-jp,euc-kr,gb18030,gb2312,gbk,ibm-thai,ibm00858,ibm01140,ibm01141,ibm01142,ibm01143,ibm01144,ibm01145,ibm01146,ibm01147,ibm01148,ibm01149,ibm037,ibm1026,ibm1047,ibm273,ibm277,ibm278,ibm280,ibm284,ibm285,ibm290,ibm297,ibm420,ibm424,ibm437,ibm500,ibm775,ibm850,ibm852,ibm855,ibm857,ibm860,ibm861,ibm862,ibm863,ibm864,ibm865,ibm866,ibm868,ibm869,ibm870,ibm871,ibm918,iso-2022-cn,iso-2022-jp,iso-2022-jp-2,iso-2022-kr,iso-8859-1,iso-8859-13,iso-8859-15,iso-8859-16,iso-8859-2,iso-8859-3,iso-8859-4,iso-8859-5,iso-8859-6,iso-8859-7,iso-8859-8,iso-8859-9,jis_x0201,jis_x0212-1990,koi8-r,koi8-u,shift_jis,tis-620,us-ascii,utf-16,utf-16be,utf-16le,utf-32,utf-32be,utf-32le,utf-8,windows-1250,windows-1251,windows-1252,windows-1253,windows-1254,windows-1255,windows-1256,windows-1257,windows-1258,windows-31j,x-big5-hkscs-2001,x-big5-solaris,x-euc-jp-linux,x-euc-tw,x-eucjp-open,x-ibm1006,x-ibm1025,x-ibm1046,x-ibm1097,x-ibm1098,x-ibm1112,x-ibm1122,x-ibm1123,x-ibm1124,x-ibm1166,x-ibm1364,x-ibm1381,x-ibm1383,x-ibm300,x-ibm33722,x-ibm737,x-ibm833,x-ibm834,x-ibm856,x-ibm874,x-ibm875,x-ibm921,x-ibm922,x-ibm930,x-ibm933,x-ibm935,x-ibm937,x-ibm939,x-ibm942,x-ibm942c,x-ibm943,x-ibm943c,x-ibm948,x-ibm949,x-ibm949c,x-ibm950,x-ibm964,x-ibm970,x-iscii91,x-iso-2022-cn-cns,x-iso-2022-cn-gb,x-iso-8859-11,x-jis0208,x-jisautodetect,x-johab,x-macarabic,x-maccentraleurope,x-maccroatian,x-maccyrillic,x-macdingbat,x-macgreek,x-machebrew,x-maciceland,x-macroman,x-macromania,x-macsymbol,x-macthai,x-macturkish,x-macukraine,x-ms932_0213,x-ms950-hkscs,x-ms950-hkscs-xp,x-mswin-936,x-pck,x-sjis_0213,x-utf-16le-bom,x-utf-32be-bom,x-utf-32le-bom,x-windows-50220,x-windows-50221,x-windows-874,x-windows-949,x-windows-950,x-windows-iso2022jp
content-length 10
content-type text/plain;charset=ISO-8859-1
corid 8737CB010AC2550431E72CBCDEEFF35B,1:1,1,0,,,AgAAATdIQgAAAAFGAAAAAQAAABFqYXZhLnV0aWwuSGFzaE1hcAAAAARIQgAAAAJGAAAAAgAAABBqYXZhLmxhbmcuU3RyaW5nAApUeG5UcmFjZUlkSEIAAAADRQAAAAIAJDg2QTYwREIzMEFDMjU1MDQzMUU3MkNCQzc2QkJFRjcxMjI2NEhCAAAABEUAAAACABNDYWxsZXIgQ29tcG9uZW50IElESEIAAAAFRQAAAAIAEENCMDExNDg2MkMyNjAwMDFIQgAAAAZFAAAAAgAPQ2FsbGVyVGltZXN0YW1wSEIAAAAHRQAAAAIADTE3NDYwMjUzMDI3ODVIQgAAAAhFAAAAAgARVXBzdHJlYW1HVUlEQ2FjaGVIQgAAAAlGAAAAAwAAABNqYXZhLnV0aWwuQXJyYXlMaXN0AAAAAA==
host api-gdc.uat.apps.uocp.givaudan.com
user-agent Java/11.0.3
x-api-key ba9LVxXX2nr78k2N4piKF7NtVJsZTcldkCwc457RU6HDUcAs
x-apigee-message-id 2efd0a15-6740-4682-949d-74c89f66966837650
x-apigee-tls-cipher TLS_AES_128_GCM_SHA256
x-apigee-tls-protocol TLSv1.3
x-apigee-tls-server-name api-gdc.uat.apps.uocp.givaudan.com
x-apigee-tracking-id 8711a7bc-dba6-433c-8386-2a3bde371bfc
x-application APOLLO
x-envoy-attempt-count 1
x-envoy-expected-rq-timeout-ms 300000
x-forwarded-for 10.128.2.6
x-forwarded-proto https
x-request-id 8711a7bc-dba6-433c-8386-2a3bde371bfc
x-timestamp 1746025302785

Request Content Not working

Method GET
URI /v1/data-analytics/products/PII/TWPaletteCockpit?%24filter=%28ingredient%20eq%20%279127501%27%29

Thanks,
Surekha

[paul-wright]

Hi Surekha,

Generally speaking, a 408 Request Timeout error in Apigee indicates that the Apigee Message Processor did not receive the entire HTTP request payload from the client within the configured I/O timeout period. This timeout can occur when the client's request is slow, or if there's a network issue preventing the client from sending the complete request data within the allowed time.

Beyond that, it is hard to tell from the information provided. I do see that:

• content-length: 10 is provided in the request in the NOT working solution. In general, content-length should not be passed with a GET request; there should be no Body.  If a client sets a non-zero content-length header in the request, and then sends no content, it's possible that a gateway, any gateway, will just throw a 408. Solution: don't send content-length when there is no content. 
• the java versions are different between the two user-agents
• and that the flows appear to be different, at least the policy list is different between the two screen shots

I'd recommend confirming there are no issues in the network path for the route that is failing.

[surekhavuchuru]

Hi Paul,

I've noticed that the content-length, Java versions, and x-apigee-tls-cipher values differ, but I'm uncertain how these variations could result in a 408 error. If there are network issues, I shouldn't see the request at all in debug mode. Furthermore, the request content for both instances seems to be the same when reviewed in debug mode. I have the Apigee debug session file, but I'm unable to attach it here.

I'm wondering if the client is having trouble connecting to Apigee, as I would typically expect to see errors like:

• Connection Timeout
• DNS Resolution Error
• Network Unreachable
• Connection Refused
• SSL/TLS Errors

Thanks,

Surekha

[paul-wright]

Hi,

If the network was completely blocking the call, yes, you would not see the trace at all. But a 408 indicates that a connection was established, that some content has been sent, but the message did not complete before the request timeout expired. 

If this call is being made from a long distance away, you could possibly increase the request timeout.

Do not let the error in the header parsing distract from the cause. Most likely the parsing of the header is failing because the message was not complete and therefore the headers could not be parsed correctly.

[surekhavuchuru]

Hi Paul,
I was finally able to replicate the issue using Postman. When I make the call with a Content-Length of 10, I encounter the same exception (it works without Content-Length). The request that failed also included a Content-Length of 10, which is the reason for this exception.

Thanks,

Surekha

[paul-wright]

Ok, that makes a lot of sense. I've tried to test scenarios with a mix of mis-matched content length and data values this morning and I get a variety of conflicts and errors across my systems (load balancers, routers, Apigee)... 

Our modern systems definitely care about that information and it needs to be correctly configured for a clean result.