You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Sangjin Lee (JIRA)" <ji...@apache.org> on 2007/12/22 01:32:43 UTC
[jira] Created: (GERONIMO-3717) Queries provided through the URL
argument to HttpRequestMessage get lost
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
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.
[jira] Updated: (GERONIMO-3717) Queries provided through the URL
argument to HttpRequestMessage get lost
Posted by "Sangjin Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sangjin Lee updated GERONIMO-3717:
----------------------------------
Attachment: 3717.patch
a suggested fix
> 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
> 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.
[jira] Resolved: (GERONIMO-3717) Queries provided through the URL
argument to HttpRequestMessage get lost
Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Closed: (GERONIMO-3717) Queries provided through the URL
argument to HttpRequestMessage get lost
Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick McGuire closed GERONIMO-3717.
----------------------------------
> 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.