What's the exact URL you are invoking this on? Is this a clean installation of the server or do you have any changes? You can get a bit more verbose output from curl by using the -v option and see if it provides a hint (you can paste those logs here too).
Thanks for the reply.
I am invoking a custom API that sleeps for 70 seconds in order to make the request time longer than 60 seconds.
We are running in standalone with few changed configurations like datasources, etc. but nothing that is related to timeout.
If you can confirm that there is no default 60 seconds timeout with Wildfly 14 - I will dig deeper into our configuration and try to find what is causing it.
Below you can find the "curl" with verbose (9444 is the port Wildfly listens on).
$ time curl -v -X GET https://192.168.1.23:9444/api/sleepSeventySeconds -H 'Authorization: Bearer eyJ...-1g' -H 'Content-Type: application/json' -H 'cache-control: no-cache' --insecure
* About to connect() to 192.168.1.23 port 9444 (#0)
* Trying 192.168.1.23...
* Connected to 192.168.1.23 (192.168.1.23) port 9444 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA
* Server certificate:
> GET /api/sleepSeventySeconds HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 192.168.1.23:9444
> Accept: */*
> Authorization: Bearer eyJ...-1g
> Content-Type: application/json
> cache-control: no-cache
* Empty reply from server
* Connection #0 to host 192.168.1.23 left intact
curl: (52) Empty reply from server
I haven't been able to reproduce this in a fresh install of WildFly 14 (and 15) with a plain servlet which sleeps for more than a minute. Both HTTP and HTTPS work fine. Are you sure there isn't some web framework or library within your application which might be playing a role? Have you tried this with a plain servlet without anything else in the application?
Thanks a lot for checking!
Indeed I also found it does not happen with a fresh WildFly 14 but it did happen when we upgraded from WildFly 13 to WildFly 14 and kept our custom configuration file without changes.
From my tests, it seems that the timeout occurs if I have the "enabled-cipher-suites" attribute in
This was my enabled-cipher-suites value: "TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA"
I tried changing the content of "enabled-cipher-suites" with different ciphers but only when I removed this attribute completely, the timeout issue was gone.
I also read that "enabled-cipher-suites" is deprecated Attribute 'enabled-cipher-suites' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated
Not sure why this causes a timeout but I believe this is the cause.