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

Jon Moore commented on HTTPCLIENT-1124:
---------------------------------------

I re-read RFC2616 and could not find a prohibition against sending bodies on 
the non-enclosing methods (GET, HEAD, DELETE, TRACE, OPTIONS), so technically 
there's nothing non-compliant about doing that (it doesn't violate any MUSTs or 
SHOULDs).

That said, it's pretty weird to want to do that, based on the described 
semantics. In fact, it's so weird, HTTP-bis explicitly says a server should 
*ignore* those bodies. So why send them in common usage? I don't see a need to 
change the existing common-case implementations.

So my opinion is that I agree with Alexey *and* Oleg: HTTP permits you to send 
bodies on these requests if for some strange reason you want to, and you can 
use a BasicHttpEntityEnclosingRequest if you want to do that. So, not a bug.


> Can't send request body with HTTP methods other than POST and PUT
> -----------------------------------------------------------------
>
>                 Key: HTTPCLIENT-1124
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1124
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 4.1.2
>            Reporter: Alexey Levan
>            Priority: Minor
>
> I'd like to have a possibility to send an HttpEntity regardless of method of 
> request.  The HTTP spec doesn't prohibit that (AFAIK, even GET requests with 
> body are allowed), and any spec-compliant implementation shouldn't do it 
> either.  I suggest merging HttpEntityEnclosingRequestBase with 
> HttpRequestBase, since there's really no reason to make this artifical 
> restriction.

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

        

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to