AbstractHttpMessageConverter + ShallowEtagHeaderFilter + manual ETag = ❌

[cfredri4]

I'm doing the following:

• Using ShallowEtagHeaderFilter
• Manually setting ETag header (because the response body contains random elements which should not be included in ETag so it cannot be generated by ShallowEtagHeaderFilter)
• Having a converter which extends AbstractHttpMessageConverter

But ShallowEtagHeaderFilter returns the raw output stream if ETag header is already set, and AbstractHttpMessageConverter flushes the output stream, which commits the response so it cannot be updated to return 304+no body.

[bclozel]

This sounds like the expected behavior. If the Etag filter sees an existing ETag header it shouldn't interfere and let the response flow.
As for the custom converter I'm not seeing the link.

Maybe a minimal sample application would make things clearer?

[cfredri4]

On second thought, the issue might not actually be caused by AbstractHttpMessageConverter; it just makes it more visible because it flushes the output.

My interpretation of ShallowEtagHeaderFilter is that it should be possible to provide your own ETag header instead of ShallowEtagHeaderFilter generating it, and that ShallowEtagHeaderFilter should still check If-None-Match header and return 304+no body even for your own ETags?
This would mean that the response always needs to be cached, even if you set your own ETags.

The javadoc for ConditionalContentCachingResponseWrapper also does not say anything about not caching if your own ETag is set.

It looks like it worked this way back in 5.1.

[bclozel]

HTTP caching is already available at the controller level with response entities and WebRequest.

If it is not the case please provide a minimal sample application and we can reopen this issue.