hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Levan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1124) Can't send request body with HTTP methods other than POST and PUT
Date Thu, 08 Sep 2011 10:51:09 GMT

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

Alexey Levan commented on HTTPCLIENT-1124:
------------------------------------------

> you can use a BasicHttpEntityEnclosingRequest

Unfortunately, I can't.  The problem is, that I use the Dispath library[1] based on HttpClient,
which not only duplicates the "POST and PUT are special" logic, but makes things worse by
silently dropping the message when it can't be sent.  As you may have guessed, that behaviour
resulted in a few hours of dbug and frustration.  And that's the real issue I want to be solved,
because if I was struck by this misbehaviour, than somebody else probably will, too.

In the specification I'm unlucky enough to implement, there's information sent in the body
of the DELETE request, for some crazy reazon.  That's perverted behaviour, as has been pointed
above. But it's compliant to the RFC spec. Conditionally compliant, per section 1.2, but still.

The problem with the current implementation is that it have an abstraction leak.  According
to the documentation and common sense, HttpGet object should be a representation of the HTTP
GET method.  But in fact it's not, it misses certain functionality.  So there happens to be
a dissonance between the object and the thing it represents.  If there weren't any Http* classes,
and users were encouraged to use BasicHttpEntityEnclosingRequest, that would be fine. If HttpGet
could have a message body, that would be fine, too.  But the current implementation encourages
using classes with reduced functionality, and that leads to problems.

Now, what should I say to the Dispath authors when I ask to fix the body stripping problem?
 Is it something along the lines "the official position of HttpClient authors is to use BasicHttpEntityEnclosingRequest
for fully spec-compliant methods, please swith to it"? Or maybe you guys could introduce that
backwards-compatible change to be closer to spec, and save some developers in future several
hours of frustration?

[1] http://dispatch.databinder.net/

> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message