The fix to protect against RFD exploits (#18124) introduced a "Content-Disposition:attachment;filename=f.txt" response header for @ResponseBody methods where the URL appears to have an extension that is neither whitelisted by default nor explicitly registered by the application.
However if you name an application with Maven conventions my-app.1.3.4-SNAPSHOT and deploy to a servlet container a Content-Disposition header is added for the URLs that match the context and/or servlet path.
Affects: 4.1.8, 4.2.2
#18165 Skip Content-Disposition header when status != 2xx ("duplicates")
The text was updated successfully, but these errors were encountered:
Stock Spring Boot app from start.spring.io with artifact=demo-app.1.3.4-SNAPSHOT does return a 404 with Content-Disposition for /demo-app.1.3.4-SNAPSHOT. That's fixed with #18165 however. I confirmed this by switching to a Spring Boot 1.3.0 snapshot. Also note that the same URL with a slash at the end is not affected to begin with (it's only a dot in the last path segment that triggers this).
For a non-Spring Boot app the issue not reproducible. The URL /demo-app.1.3.4-SNAPSHOT returns 302 while for /demo-app.1.3.4-SNAPSHOT/ it depends on the mapping for "/". If mapped to a home HTML page there is no issue since we only add Content-Disposition for response body rendering.
So the only way I see this being a potential issue is if there is @ResponseBody rendering for the context path URL. At that point this is probably not meant for rendering in a browser anyway while a home HTML page wouldn't have the issue to begin with.