[
https://issues.apache.org/jira/browse/DIRMINA-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503755#comment-13503755
]
Julien Vermillard commented on DIRMINA-920:
-------------------------------------------
Agreeing on empty content, but for content on GET I'm not really sure we want
to authorize that.
Reading the RFC http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3 I
feel like it's not a good use case, but I wonder if it's really forbidden.
Perhaps we should support that and let the user code ignore.
> HTTP server decoding is broken
> ------------------------------
>
> Key: DIRMINA-920
> URL: https://issues.apache.org/jira/browse/DIRMINA-920
> Project: MINA
> Issue Type: Bug
> Components: Protocol - HTTP
> Affects Versions: 2.0.7
> Reporter: Jeff MAURY
> Labels: HTTP, protocol, states
> Fix For: 2.0.8, 3.0.0-M1
>
>
> HTTP server decoding (aka HttpServerDecoder) is broken is several parts:
> 1) it make the assertion that PUT and POST request must have a non -zero
> length body. This is false, thing about REST request: an empty PUT request
> can be use to create a server initialized entry and an empty POST request can
> be used to change properties where the value is stored in the URL
> (/rest/1234/status/cancelled). In that case, an exception is thrown but the
> state is not reset so remaining decoding will fail
> 2) it also make the assumption that only PUT and POST request can have a body
> where I can't find a significant case but I tried a GET request with a body
> on Google (GPE), Microsoft (IIS) and Apache (Apache) and Google was the only
> server to reject the request as malformed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
