When using SSE (Server-Sent Events) technology in Spring, the response typically includes a Chunked header and the text/event-stream content type.

An issue arises when response caching occurs before the Chunked header is assigned, resulting in the content-length being set. In HTTP, if a response has both the Chunked type and a set content-length, it does not function as intended in chunked mode.

This change ensures that even if caching occurs before the Chunked header is assigned, the content-length is not set, allowing for proper functionality.

Comment From: pivotal-cla

@jkshin0602 Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

Comment From: pivotal-cla

@jkshin0602 Thank you for signing the Contributor License Agreement!

Comment From: bclozel

Thanks for your contribution, but this check is really out of place here. If a response should not be cached, the check should be performed beforehand and avoid the wrapping altogether (you can see that in action in ShallowEtagHeaderFilter.

Maybe your streaming endpoint should call ShallowEtagHeaderFilter#disableContentCaching if you're using this filter? If your code is not using this filter, you will need to figure out a similar mechanism.

Comment From: jkshin0602

@bclozel The caching you're referring to seems to be client-side caching, while the caching I'm talking about is server-side caching that allows reading the response multiple times. It seems we could use the class you mentioned for the purpose of caching to allow multiple reads, as I intended. I'm still curious if my PR logic was incorrect. To summarize, caching is needed to read the body multiple times -> I want to directly log the response.

  1. Client-side caching (e.g., using ETag headers), which is handled by ShallowEtagHeaderFilter.
  2. Server-side response content caching, which allows multiple reads of the response body.

My intention is to implement the latter - caching the response content on the server side to enable logging of the response body. This use case is different from the client-side caching mechanism that ShallowEtagHeaderFilter addresses.

Please review again Thank you for your time and consideration.

Comment From: bclozel

I did point to ShallowEtagHeaderFilter not for the HTTP caching headers, but for the fact that indeed it caches the response content for multiple reads. My analysis still stands, your code should check the response content type before caching its content in memory, as this is the case in the Spring Framework codebase through multiple ShallowEtagHeaderFilter#disableContentCaching calls.