search

jakartaee / servlet

Jakarta Servlet
https://eclipse.org/ee4j/servlet
Other
263 stars 85 forks source link

Require that filters that modify the response body must address content length and range requests #25

Open glassfishrobot opened 13 years ago

glassfishrobot commented 13 years ago

If a filter modifies the response body it may cause problems for a servlet if the servlets set a content length or respond correctly to range requests.

The specification currently implies that wrapping the response is necessary if the response body is modified. This issue requests that filters that modify the response body are required to correctly handle (which will almost certainly mean wrapping the response) range requests and the content-length of the response.

glassfishrobot commented 6 years ago
glassfishrobot commented 13 years ago

@glassfishrobot Commented Reported by markt_asf

glassfishrobot commented 11 years ago

@glassfishrobot Commented mode said: Isn't it the job of the filter? Do you want the specification to state that the Response MUST be wrapped if the response is modified?

glassfishrobot commented 11 years ago

@glassfishrobot Commented markt_asf said: This came out of a Filter in one of the TCK tests modifying a resource returned by Tomcat's default servlet and the test failing because the Filter lengthened the request body but left the content length header unchanged. My aim with this request was to push responsibility for failures in this case onto the Filter.

I've done some further thinking on this. Since not all Servlets will return a range for a range request or set an explicit content length it seems unreasonable to expect all Filters that modify response bodies to ensure range requests and content length issues are correctly handled. I don't think we should place an unnecessary burden on Filter developers. On that other hand, I'd like the specification to be clearer about the consequences of a Filter modifying a response body and where the responsibility lies if it breaks. How about along the lines of the following - probably at the end of section 6.1:

"Filters that modify the response body generated by a Servlet SHOULD not break the functionality of that Servlet. For example, if the Servlet supports range requests or sets an explicit content-length, the Filter SHOULD take steps to ensure that the response to the client is correct."

Part of me would like to replace the "SHOULD"s with "MUST"s but I think that would be too prescriptive.

glassfishrobot commented 11 years ago

@glassfishrobot Commented mode said: The problem with this is that even though the target Servlet may support range, content-length etc, how does the filter find out? Also a subsequent Filter in the filter chain may dispatch the request to some other servlet altogether. I am ok with the line you suggest above, but that does not guarantee that all containers will implement it that way.

glassfishrobot commented 7 years ago

@glassfishrobot Commented This issue was imported from java.net JIRA SERVLET_SPEC-25

manorrock commented 3 years ago

@gregw As a Filter can be anywhere in the FilterChain I would recommend here to sharpen the language a bit towards something like this "Be aware that any Filter that modifies the ServletResponse can potentially break a subsequent Filter or the Servlet in the FilterChain. It is the responsibility of the Filter developer to clearly describe what it does with the ServletResponse so a user of the Filter is aware of what happens when they add the Filter".