Problem with 304 Not Modified responses on WildFly 9.0.2.Final and Spring Boot

[pvorb]

(I already posted this issue at Github where lafr pointed me to the JBoss Forums.)

I experienced some unexpected behavior with a Spring Boot application I've been running on WildFly 9.0.2.Final.

Description

When I send a request including an If-Modified-Since header with cURL to a static resource that is served by the Spring Boot application, and the server answers with a 304 Not Modified status, the cURL request does not return. The response is Transfer-Encoding: chunked, so probably the final chunk never gets sent by WildFly.

Reproducing

In order to make it reproducible, I've created a minimal example application:https://github.com/pvorb/wildfly-spring-boot-sample

Just clone the repository and run mvn package. The resulting WAR file can be deployed in a fresh WildFly installation.

After the artifact is deployed, you can request the static resource with cURL:

$ curl -v -X GET -H 'If-Modified-Since: Mon, 11 Jan 2016 20:14:14 GMT' 'http://localhost:8080/sample.txt'
* timeout on name lookup is not supported
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /sample.txt HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.44.0
> Accept: */*
> If-Modified-Since: Mon, 11 Jan 2016 20:14:14 GMT
>
< HTTP/1.1 304 Not Modified
< Connection: keep-alive
< X-Powered-By: Undertow/1
< Server: WildFly/9
< Transfer-Encoding: chunked
< Date: Mon, 11 Jan 2016 23:55:18 GMT
< 

You need to change the date in the If-Modified-Since header so it responds with 304 Not Modified. Note that the command never returns until you hit CTRL-C.

In order to check if this behavior really is related to WildFly, I also made a version of the application that uses an embedded Undertow web server. You can try that version by checking out the feature branchfeature/standalone and then run it.

$ git checkout feature/standalone
$ mvn spring-boot:run 

Then you can repeat the cURL request:

$ curl -v -X GET -H 'If-Modified-Since: Mon, 11 Jan 2016 20:14:14 GMT' 'http://localhost:8080/sample.txt'
* timeout on name lookup is not supported
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /sample.txt HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.44.0
> Accept: */*
> If-Modified-Since: Mon, 11 Jan 2016 20:14:14 GMT
>
< HTTP/1.1 304 Not Modified
< Connection: keep-alive
< Content-Length: 0
< Date: Tue, 12 Jan 2016 00:09:04 GMT
<
* Connection #0 to host localhost left intact

Note that the request actually ends and cURL returns to the command line, but also there's Content-Length: 0 instead of Transfer-Encoding: chunked so I'm not 100% certain that the problem is really caused by WildFly.

Further notes

If you do a similar request in a browser (I've tested Firefox and Chrome) the response will be accepted and correctly handled. I came across this behavior in a scenario where I made requests from a browser to a similar Spring Boot on WildFly application from behind a proxy. The first request to static resources are handled correctly with a Last-Modified header, which causes the browser to send subsequent requests to the same resource with a If-Modified-Since header. These subsequent requests never return. Probably the proxy is implemented in a similar way like cURL, so it is not forgiving the missing final chunk.

Questions

• Can you reproduce the behavior?
• Do you think it's a bug in WildFly (or probably Undertow) or is it more likely to be caused by Spring Boot or even cURL as well as the proxy?

Any help is appreciated since the behavior is causing me headaches. I've found a workaround that prevents Spring Boot from setting the Last-Modified header, but that's not attacking the real issue.

Fixed line breaks in code blocks.

[pvorb]

I tested the same artifact on WildFly 10.0.0.CR5 where the problem doesn't occur.