You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Ryan Stewart (JIRA)" <ji...@apache.org> on 2010/04/02 16:24:27 UTC
[jira] Created: (HTTPCLIENT-930) Unencoded redirect URI causes
exception when following redirects
Unencoded redirect URI causes exception when following redirects
----------------------------------------------------------------
Key: HTTPCLIENT-930
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-930
Project: HttpComponents HttpClient
Issue Type: Bug
Components: HttpClient
Affects Versions: 4.0.1
Reporter: Ryan Stewart
When HttpClient is set to follow redirects, the DefaultRedirectHandler gets the redirect location from the appropriate request header and attempts to create a new java.net.URI from it. If the location contains an invalid URI character, creating the URI fails. For example, if the redirect location were "/foo?bar=<baz/>", it would fail because the '<' and '>' are not legal in a URI.
I'm not sure if this should actually be considered a bug in HttpClient, since the website in question should probably be responsible for encoding the URI appropriately; however, browsers handle the situation gracefully, and it would be nice if this excellent library would do so as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Resolved: (HTTPCLIENT-930) Unencoded redirect URI causes
exception when following redirects
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCLIENT-930.
------------------------------------------
Resolution: Fixed
Fix Version/s: 4.1 Alpha2
Implemented in SVN trunk:
http://svn.apache.org/viewvc?rev=930560&view=rev
Please note HttpClient 4.1 uses newer interface RedirectStrategy instead of deprecated RedirectHandler
Oleg
> Unencoded redirect URI causes exception when following redirects
> ----------------------------------------------------------------
>
> Key: HTTPCLIENT-930
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-930
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.0.1
> Reporter: Ryan Stewart
> Fix For: 4.1 Alpha2
>
>
> When HttpClient is set to follow redirects, the DefaultRedirectHandler gets the redirect location from the appropriate request header and attempts to create a new java.net.URI from it. If the location contains an invalid URI character, creating the URI fails. For example, if the redirect location were "/foo?bar=<baz/>", it would fail because the '<' and '>' are not legal in a URI.
> I'm not sure if this should actually be considered a bug in HttpClient, since the website in question should probably be responsible for encoding the URI appropriately; however, browsers handle the situation gracefully, and it would be nice if this excellent library would do so as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-930) Unencoded redirect URI causes
exception when following redirects
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852929#action_12852929 ]
Oleg Kalnichevski commented on HTTPCLIENT-930:
----------------------------------------------
We had similar reports in the past and they all were rejected as invalid, see HTTPCLIENT-778 for example.
I am also not sure the way browsers handle this kind of problems can be defined as graceful. I _suspect_ that browsers simply use the good ol' principle of garbage in - garbage out and do not even attempt to escape redirect urls.
What theoretically can be done about is the following: the abs_path and query parts of the redirect URI are scanned for illegal characters and if any is found the entire URI is considered un-escaped. This of course does not help if you have situations like that:
/garbage%20in%20garbage%20?param={screw you all}.
Bottom line: malformed request URIs are inherently ambiguous and there is nothing that can be done about it.
Oleg
> Unencoded redirect URI causes exception when following redirects
> ----------------------------------------------------------------
>
> Key: HTTPCLIENT-930
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-930
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.0.1
> Reporter: Ryan Stewart
>
> When HttpClient is set to follow redirects, the DefaultRedirectHandler gets the redirect location from the appropriate request header and attempts to create a new java.net.URI from it. If the location contains an invalid URI character, creating the URI fails. For example, if the redirect location were "/foo?bar=<baz/>", it would fail because the '<' and '>' are not legal in a URI.
> I'm not sure if this should actually be considered a bug in HttpClient, since the website in question should probably be responsible for encoding the URI appropriately; however, browsers handle the situation gracefully, and it would be nice if this excellent library would do so as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-930) Unencoded redirect URI causes
exception when following redirects
Posted by "Ryan Stewart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853073#action_12853073 ]
Ryan Stewart commented on HTTPCLIENT-930:
-----------------------------------------
Yeah, I can't disagree with any of that. For my application, at least, I'll have to try the "escape if it looks unescaped" thing. If you don't want to add support for that in HttpClient, can I get a new method in DefaultRedirectHandler that I can override and add this behavior to? Either:
protected String getLocation(HttpResponse response) { ... }
or
protected URI createLocationUri(String location) { ... }
Extract one (or both) of these methods from the getLocationURI method, and then I could encode the string either after it gets extracted from the response or before the URI is built.
> Unencoded redirect URI causes exception when following redirects
> ----------------------------------------------------------------
>
> Key: HTTPCLIENT-930
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-930
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.0.1
> Reporter: Ryan Stewart
>
> When HttpClient is set to follow redirects, the DefaultRedirectHandler gets the redirect location from the appropriate request header and attempts to create a new java.net.URI from it. If the location contains an invalid URI character, creating the URI fails. For example, if the redirect location were "/foo?bar=<baz/>", it would fail because the '<' and '>' are not legal in a URI.
> I'm not sure if this should actually be considered a bug in HttpClient, since the website in question should probably be responsible for encoding the URI appropriately; however, browsers handle the situation gracefully, and it would be nice if this excellent library would do so as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org