|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
|
|
[jira] Created: (WW-2641) Separate request content-type from the response content-type handlingSeparate 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[ 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[ 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. |
| Free Forum Powered by Nabble | Forum Help |