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

Alexander Klimetschek commented on SLING-1974:
----------------------------------------------

> The reason for the filter is that we are more flexible and I don't want to 
> grow the Engine too much. 

Sling's SlingHttpServletRequest API defines getResponseContentType(), so I 
wonder why this should be implemented in a filter and not in 
SlingHttpServletRequestImpl itself (making the current implementation of it 
useless). Servlet filters IMO only make sense if an application wants to 
generally wrap things for all servlets, if an applications wants to overwrite 
servlet-container default logic or have something that is active or not 
depending on the request.

In this case however, I think we agree that this is core framework logic. Only 
if someone wants to change it, she could write a filter to provide a different 
logic for response content types.

> Accept header issues in the Sling POST Servlet
> ----------------------------------------------
>
>                 Key: SLING-1974
>                 URL: https://issues.apache.org/jira/browse/SLING-1974
>             Project: Sling
>          Issue Type: Bug
>          Components: Servlets
>    Affects Versions: Servlets Post 2.1.0
>            Reporter: Felix Meschberger
>             Fix For: Servlets Post 2.1.2
>
>         Attachments: SLING-1974.patch
>
>
> As of SLING-1336 the Sling POST Servlet can interpret the Accept request 
> header to select what response content type to render.
> Unfortunately that handling seems broken as for an Accept header like (as 
> generated by FireFox with the JSONovich plugin installed) :
>    Accept: 
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json
> the JSON response might be selected but sometimes also text/html (we can 
> observe both behaviours for different server platforms with our application).
> The Accept header should probably consider equivalent q values (as for 
> text/html and application/json in the example) to solve the tie by selecting 
> the first type list; thus text/html in this example.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to