[
https://issues.apache.org/jira/browse/GERONIMO-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick McGuire resolved GERONIMO-3717.
------------------------------------
Resolution: Fixed
Assignee: Rick McGuire
Committed revision 608104.
Thanks Sangjin!
> Queries provided through the URL argument to HttpRequestMessage get lost
> ------------------------------------------------------------------------
>
> Key: GERONIMO-3717
> URL: https://issues.apache.org/jira/browse/GERONIMO-3717
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: AsyncHttpClient
> Affects Versions: 1.x
> Reporter: Sangjin Lee
> Assignee: Rick McGuire
> Attachments: 3717.patch
>
>
> There are two different ways of providing a query parameter to
> HttpRequestMessage, and both ways should be supported. One way is through
> the URL argument in the HttpRequestMessage constructor, and the other is via
> HttpRequestMessage.setParameter(). However, if you supply a query parameter
> via the former, it gets lost, and is not sent.
> For example, suppose you want to make a request to
> "http://some_host/path?foo=bar";. One way to construct the request object is
> HttpRequestMessage msg = new HttpRequestMessage(new
> URL("http://some_host/path?foo=bar";, cb);
> The other way is
> HttpRequestMessage msg = new HttpRequestMessage(new
> URL("http://some_host/path";), cb);
> msg.setParameter("foo", "bar");
> However, the encoder (HttpRequestEncoder) uses only URL.getPath() (which
> returns only "/path" in this example) to form the request line. The correct
> method it should have used is URL.getFile() (which returns "/path?foo=bar" in
> this example).
> It is apparent that AHC expects to support both usages, as there is code that
> tries to add any parameter in addition to any existing queries already in the
> URL, except it's not done quite right.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
