[ 
https://issues.apache.org/jira/browse/SLING-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655391#comment-15655391
 ] 

Rob Ryan commented on SLING-6271:
---------------------------------

[~asanso] Can you review these and let me know which approach you favor, and or 
commit whichever one that is :-) Thanks.

> ContentDispositionFilter can suppress content type upon request forwarding
> --------------------------------------------------------------------------
>
>                 Key: SLING-6271
>                 URL: https://issues.apache.org/jira/browse/SLING-6271
>             Project: Sling
>          Issue Type: Bug
>          Components: Extensions
>    Affects Versions: Security 1.1.0
>            Reporter: Rob Ryan
>         Attachments: conservative.patch.txt, simple.patch.txt
>
>
> In SLING-4604 Alessandro Bonfatti noted a use case whereby a response would 
> contain no Content-Type header despite a similar non-forwarded request would 
> have a Content-Type. He further traced it to the ContentDispositionFilter and 
> the change where I introduced a shortcut in cases the same content type was 
> being set repeatedly.
> The scenario is:
> setContentType is called
> RequestDispatcher.forward is used to forward a request to a new servlet for 
> further handling. 
> setContentType is called.
> As of SLING-4604, the second setContentType call will be ignored if it sets 
> the same content type. But even if it *is* the same, setContentType needs to 
> be called again because request forwarding clears all headers with 
> response.reset().
> I will attach two patches, one (simple) very simple, and the best performing. 
> The other (conservative) is more complex, but should still perform adequately 
> and is conservative in the following senses:
> It will always call super.setContentType when its setContentType is invoked.
> On each setContentType it will re-apply the Content-Disposition header if 
> there is not one present and the 'attachment' value is called for by the 
> configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to