[
https://issues.apache.org/jira/browse/SYNAPSE-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779811#action_12779811
]
Asankha C. Perera commented on SYNAPSE-587:
-------------------------------------------
Hi Hiranya
Not sure I understand the requirement correctly.. if a content type is not
specified, is it wrong to assume binary? Does it fail any known use cases?
I am particularly interested in ensuring that full REST support does go into
1.3 release, as a user is waiting to use this facility.. and hence would be
grateful if you could ensure the fixes for it is not broken, and take this case
separate if possible
thanks
asankha
> NHTTP Transport Does Not Handle Responses With No Content-Type Header Properly
> ------------------------------------------------------------------------------
>
> Key: SYNAPSE-587
> URL: https://issues.apache.org/jira/browse/SYNAPSE-587
> Project: Synapse
> Issue Type: Bug
> Components: Transports
> Affects Versions: 1.2, NIGHTLY
> Environment: Any
> Reporter: Hiranya Jayathilaka
> Assignee: Hiranya Jayathilaka
> Fix For: 1.3
>
>
> Currently the NHTTP transport would assume an empty payload for response
> messages which do not have the HTTP Content-Type header. According to the
> HTTP/1.1 specification this should be handled as follows.
> <quote>
> Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type
> header field defining the media type of that body. If and only if the media
> type is not given by a Content-Type field, the recipient MAY attempt to guess
> the media type via inspection of its content and/or the name extension(s) of
> the URI used to identify the resource. If the media type remains unknown, the
> recipient SHOULD treat it as type "application/octet-stream".
> </quote>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
