You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Jeromy Evans (JIRA)" <ji...@apache.org> on 2008/05/11 05:22:05 UTC
[jira] Created: (WW-2641) Separate request content-type from the
response content-type handling
Separate request content-type from the response content-type handling
---------------------------------------------------------------------
Key: WW-2641
URL: https://issues.apache.org/struts/browse/WW-2641
Project: Struts 2
Issue Type: Improvement
Components: Plugin - REST
Affects Versions: 2.1.2
Reporter: Jeromy Evans
Assignee: Jeromy Evans
The REST plugin's ContentTypeHandlerManager assumes the content-type of the request and content-type of the response are both determined by the request extension (eg. .json, .xml).
However, a common use-case for browser user-agents is that the request content type will be "application/x-www-form-urlencoded" or "application/form-multipart" with a JSON, XML or HTML response content type.
Proposal: split the ContentTypeHandlerManager to implement getHandlerForRequest() and getHandlerForResponse() methods. The request handler should inspect the request content type and give precedence to the handler for the content type first, falling-back to the handler for the extension if not found/not specified. The Response handler will continue to use the extension (later it should use the accepts request header).
Registration of ContentTypeHandlers will place the handler in the appropriate request/response handlers map depending on the extension (if present) and content type (if present). Overrides will still only apply to the extension at this time.
This change will also add a new default ContentTypeHandler for "application/x-www-form-urlencoded" requests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WW-2641) Separate request content-type from the
response content-type handling
Posted by "Don Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Don Brown updated WW-2641:
--------------------------
Fix Version/s: 2.1.3
> Separate request content-type from the response content-type handling
> ---------------------------------------------------------------------
>
> Key: WW-2641
> URL: https://issues.apache.org/struts/browse/WW-2641
> Project: Struts 2
> Issue Type: Improvement
> Components: Plugin - REST
> Affects Versions: 2.1.2
> Reporter: Jeromy Evans
> Assignee: Jeromy Evans
> Fix For: 2.1.3
>
>
> The REST plugin's ContentTypeHandlerManager assumes the content-type of the request and content-type of the response are both determined by the request extension (eg. .json, .xml).
> However, a common use-case for browser user-agents is that the request content type will be "application/x-www-form-urlencoded" or "application/form-multipart" with a JSON, XML or HTML response content type.
> Proposal: split the ContentTypeHandlerManager to implement getHandlerForRequest() and getHandlerForResponse() methods. The request handler should inspect the request content type and give precedence to the handler for the content type first, falling-back to the handler for the extension if not found/not specified. The Response handler will continue to use the extension (later it should use the accepts request header).
> Registration of ContentTypeHandlers will place the handler in the appropriate request/response handlers map depending on the extension (if present) and content type (if present). Overrides will still only apply to the extension at this time.
> This change will also add a new default ContentTypeHandler for "application/x-www-form-urlencoded" requests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WW-2641) Separate request content-type from the
response content-type handling
Posted by "Jeromy Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeromy Evans resolved WW-2641.
------------------------------
Resolution: Implemented
A new ContentTypeHandler is added for x-www-form-urlencoded and the ContentTypeHandlerManager's functionality split to get a handler for the request and response separately. The ContentTypeHandlerManager also allows handlers to be registered by mime-type and/or extension.
> Separate request content-type from the response content-type handling
> ---------------------------------------------------------------------
>
> Key: WW-2641
> URL: https://issues.apache.org/struts/browse/WW-2641
> Project: Struts 2
> Issue Type: Improvement
> Components: Plugin - REST
> Affects Versions: 2.1.2
> Reporter: Jeromy Evans
> Assignee: Jeromy Evans
> Fix For: 2.1.3
>
>
> The REST plugin's ContentTypeHandlerManager assumes the content-type of the request and content-type of the response are both determined by the request extension (eg. .json, .xml).
> However, a common use-case for browser user-agents is that the request content type will be "application/x-www-form-urlencoded" or "application/form-multipart" with a JSON, XML or HTML response content type.
> Proposal: split the ContentTypeHandlerManager to implement getHandlerForRequest() and getHandlerForResponse() methods. The request handler should inspect the request content type and give precedence to the handler for the content type first, falling-back to the handler for the extension if not found/not specified. The Response handler will continue to use the extension (later it should use the accepts request header).
> Registration of ContentTypeHandlers will place the handler in the appropriate request/response handlers map depending on the extension (if present) and content type (if present). Overrides will still only apply to the extension at this time.
> This change will also add a new default ContentTypeHandler for "application/x-www-form-urlencoded" requests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.