[GitHub] garydgregory commented on a change in pull request #105: [HTTPCORE-572] Move examples to the src/test folders for each module.
garydgregory commented on a change in pull request #105: [HTTPCORE-572] Move
examples to the src/test folders for each module.
URL:
https://github.com/apache/httpcomponents-core/pull/105#discussion_r256618310
##
File path: pom.xml
##
@@ -185,7 +185,15 @@
${basedir}/target/site/examples
- src/examples
+
src/test/java/org/apache/hc/core5/http/examples
Review comment:
@ok2c ,
Thank you for the review. I committed your requested changes.
Gary
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] ok2c opened a new pull request #106: Immutable httpentities
ok2c opened a new pull request #106: Immutable httpentities URL: https://github.com/apache/httpcomponents-core/pull/106 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] ok2c commented on a change in pull request #105: [HTTPCORE-572] Move examples to the src/test folders for each module.
ok2c commented on a change in pull request #105: [HTTPCORE-572] Move examples
to the src/test folders for each module.
URL:
https://github.com/apache/httpcomponents-core/pull/105#discussion_r256602682
##
File path: pom.xml
##
@@ -185,7 +185,15 @@
${basedir}/target/site/examples
- src/examples
+
src/test/java/org/apache/hc/core5/http/examples
Review comment:
@garydgregory May I suggest that `maven-resources-plugin` section be moved
to individual module poms? Module specific stuff in the main project pom looks
a bit dodgy now.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
Re: Formal code reviews and PRs
Am 2019-02-13 um 17:08 schrieb Oleg Kalnichevski: Folks Since HttpComponents migration to GitBox I have been committing all my code changes to a feature branch and leaving them sit there for a day or two prior to merging them to a development branch (master or stable version branches). If there is anyone interested in doing formal code reviews of my changes please do let me know. I'll start raising PRs at GitHub for all my feature branches. I think this is a good idea. We are doing this with Maven also to gain more attraction and thus more reviewers. You should leave people at least three days to review. A day is just too short. Michael - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCORE-572) Move examples to the src/test folders for each module
Gary Gregory created HTTPCORE-572: - Summary: Move examples to the src/test folders for each module Key: HTTPCORE-572 URL: https://issues.apache.org/jira/browse/HTTPCORE-572 Project: HttpComponents HttpCore Issue Type: Improvement Components: Examples Reporter: Gary Gregory Assignee: Gary Gregory I think it would be better if our examples lived in a .examples. package under the src/test folder. The advantages are: - Examples would always be compiled by Maven and IDEs - Examples would end up living in the test jar, which would be handy for testing certain use-cases. In my case, testing using our static file server and proxy. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] garydgregory opened a new pull request #105: [HTTPCORE-572] Move examples to the src/test folders for each module.
garydgregory opened a new pull request #105: [HTTPCORE-572] Move examples to the src/test folders for each module. URL: https://github.com/apache/httpcomponents-core/pull/105 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-572) Move examples to the src/test folders for each module
[ https://issues.apache.org/jira/browse/HTTPCORE-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767397#comment-16767397 ] ASF subversion and git services commented on HTTPCORE-572: -- Commit 499c549c841bd5eca89997ad809e7d832903d89a in httpcomponents-core's branch refs/heads/HTTPCORE-572 from Gary Gregory [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=499c549 ] [HTTPCORE-572] Move examples to the src/test folders for each module. > Move examples to the src/test folders for each module > - > > Key: HTTPCORE-572 > URL: https://issues.apache.org/jira/browse/HTTPCORE-572 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: Examples >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > > I think it would be better if our examples lived in a .examples. package > under the src/test folder. The advantages are: > > - Examples would always be compiled by Maven and IDEs > - Examples would end up living in the test jar, which would be handy for > testing certain use-cases. In my case, testing using our static file server > and proxy. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Closed] (HTTPASYNC-148) ResponseContentEncoding not working with HttpAsyncClient
[
https://issues.apache.org/jira/browse/HTTPASYNC-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siqi Li closed HTTPASYNC-148.
-
> ResponseContentEncoding not working with HttpAsyncClient
>
>
> Key: HTTPASYNC-148
> URL: https://issues.apache.org/jira/browse/HTTPASYNC-148
> Project: HttpComponents HttpAsyncClient
> Issue Type: Bug
>Affects Versions: 4.1.4
> Environment: Windows 10, Oracle JDK 1.8.0_161
>Reporter: Siqi Li
>Priority: Major
>
> Here's my code snippet:
> {code:java}
> import java.io.ByteArrayInputStream;
> import java.util.zip.GZIPInputStream;
> import org.apache.commons.io.IOUtils;
> import org.apache.http.HttpResponse;
> import org.apache.http.client.methods.HttpGet;
> import org.apache.http.client.protocol.RequestAcceptEncoding;
> import org.apache.http.client.protocol.ResponseContentEncoding;
> import org.apache.http.impl.nio.client.CloseableHttpAsyncClient;
> import org.apache.http.impl.nio.client.HttpAsyncClients;
> import org.apache.http.util.EntityUtils;
> public class Issue20190211 {
> public static void main(String[] args) throws Exception {
> try (CloseableHttpAsyncClient client = HttpAsyncClients.custom()
> .addInterceptorFirst(new
> RequestAcceptEncoding())
> .addInterceptorFirst(new
> ResponseContentEncoding())
> .build()) {
> client.start();
> final HttpResponse response = client.execute(
> new HttpGet("http://example.com";),
> null).get();
> final byte[] respBytes =
> EntityUtils.toByteArray(response.getEntity());
> System.out.println(new String(respBytes, "UTF-8")); //
> Prints gibberish
> final String decompressed = IOUtils.toString(
> new GZIPInputStream(new
> ByteArrayInputStream(respBytes)), "UTF-8");
> System.out.println(decompressed); // This gives me the
> correct result
> }
> }
> }
> {code}
> What this looks like to me is that the HttpRequestInterceptor is working,
> since the server is responding with gzipped content, but the
> HttpResponseInterceptor is not, since I still have to manually decompress the
> content.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
Formal code reviews and PRs
Folks Since HttpComponents migration to GitBox I have been committing all my code changes to a feature branch and leaving them sit there for a day or two prior to merging them to a development branch (master or stable version branches). If there is anyone interested in doing formal code reviews of my changes please do let me know. I'll start raising PRs at GitHub for all my feature branches. Cheers Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] ok2c commented on a change in pull request #136: HTTPCLIENT-1968
ok2c commented on a change in pull request #136: HTTPCLIENT-1968
URL:
https://github.com/apache/httpcomponents-client/pull/136#discussion_r256437720
##
File path: httpclient/src/main/java/org/apache/http/client/utils/URIUtils.java
##
@@ -129,7 +129,8 @@ public static URI createURI(
public static URI rewriteURI(
final URI uri,
final HttpHost target,
-final boolean dropFragment) throws URISyntaxException {
+final boolean dropFragment,
Review comment:
@cstamas Is there any chance you could avoid using multiple boolean
parameters and replace them with an enum?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] cstamas opened a new pull request #136: HTTPCLIENT-1968
cstamas opened a new pull request #136: HTTPCLIENT-1968 URL: https://github.com/apache/httpcomponents-client/pull/136 https://issues.apache.org/jira/browse/HTTPCLIENT-1968 Make the normalization optional (default == true) based on `RequestConfig` setting. All the legacy spots just keep "default" behaviour, while the current bits are obeying the new param in request config. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Move Examples into a package in the test folder
I am trying to build the site to make sure I can, before I change anything and I noticed that on http://hc.apache.org/httpcomponents-core-5.0.x/project-info.html All of the links on the RHS menu under "Modules" are broken. Gary On Wed, Feb 13, 2019 at 7:59 AM Oleg Kalnichevski wrote: > On Wed, 2019-02-13 at 07:46 -0500, Gary Gregory wrote: > > Hi All: > > > > I think it would be better if our examples lived in a .examples. > > package > > under the src/test folder. The advantages are: > > > > - Examples would always be compiled by Maven and IDEs > > - Examples would end up living in the test jar, which would be handy > > for > > testing certain use-cases. In my case, testing using our static file > > server > > and proxy. > > > > WDYT? > > > > Gary > > Hi Gary > > The reason examples reside in a separate folder is make it easier to > publish them to the project website and to package with binary > distributions. > > Feel free to move the examples but please try and keep site generation > working. It is quite brittle. > > https://github.com/apache/httpcomponents-core/blob/master/pom.xml#L175 > > Cheers > > Oleg > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
Re: Move Examples into a package in the test folder
On Wed, 2019-02-13 at 07:46 -0500, Gary Gregory wrote: > Hi All: > > I think it would be better if our examples lived in a .examples. > package > under the src/test folder. The advantages are: > > - Examples would always be compiled by Maven and IDEs > - Examples would end up living in the test jar, which would be handy > for > testing certain use-cases. In my case, testing using our static file > server > and proxy. > > WDYT? > > Gary Hi Gary The reason examples reside in a separate folder is make it easier to publish them to the project website and to package with binary distributions. Feel free to move the examples but please try and keep site generation working. It is quite brittle. https://github.com/apache/httpcomponents-core/blob/master/pom.xml#L175 Cheers Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Move Examples into a package in the test folder
Hi All: I think it would be better if our examples lived in a .examples. package under the src/test folder. The advantages are: - Examples would always be compiled by Maven and IDEs - Examples would end up living in the test jar, which would be handy for testing certain use-cases. In my case, testing using our static file server and proxy. WDYT? Gary
[jira] [Commented] (HTTPCLIENT-1968) Encoded forward slashes are not preserved when rewriting URI
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767109#comment-16767109 ] Stas Gromov commented on HTTPCLIENT-1968: - It's not always possible to change the silliness on the server side. Another case - tests. I need to write test on java to check how the server is processing such requests. No chance again. > Encoded forward slashes are not preserved when rewriting URI > > > Key: HTTPCLIENT-1968 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1968 > Project: HttpComponents HttpClient > Issue Type: Bug >Affects Versions: 4.5.7 >Reporter: Jay Modi >Priority: Major > Attachments: rewrite_preserve_forward_slash.diff > > > URIs that contain an encoded forward slash (%2F) are no longer preserved when > the HTTP client executes. I came across this when upgrading from 4.5.2 to > 4.5.7 and my requests that contained an encoded forward slash suddenly > started failing. The appears to be due to decoding and re-encoding of the > path that takes place in the URIUtils#rewriteURI method. I've attached a > patch that restores the old behavior but if a URI contains two slashes in a > row in addition to an encoded slash the encoded forward slash will be decoded. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1968) Encoded forward slashes are not preserved when rewriting URI
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767112#comment-16767112 ] Stas Gromov commented on HTTPCLIENT-1968: - your rudeness is the stopper for a productive dialog, bye > Encoded forward slashes are not preserved when rewriting URI > > > Key: HTTPCLIENT-1968 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1968 > Project: HttpComponents HttpClient > Issue Type: Bug >Affects Versions: 4.5.7 >Reporter: Jay Modi >Priority: Major > Attachments: rewrite_preserve_forward_slash.diff > > > URIs that contain an encoded forward slash (%2F) are no longer preserved when > the HTTP client executes. I came across this when upgrading from 4.5.2 to > 4.5.7 and my requests that contained an encoded forward slash suddenly > started failing. The appears to be due to decoding and re-encoding of the > path that takes place in the URIUtils#rewriteURI method. I've attached a > patch that restores the old behavior but if a URI contains two slashes in a > row in addition to an encoded slash the encoded forward slash will be decoded. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1968) Encoded forward slashes are not preserved when rewriting URI
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767110#comment-16767110
]
Oleg Kalnichevski commented on HTTPCLIENT-1968:
---
{quote}I can't do it with 4.5.7. I have no chances{quote}
Wrong.
And the idea of fixing the parser of the server side has not crossed your mind
at all?
Oleg
> Encoded forward slashes are not preserved when rewriting URI
>
>
> Key: HTTPCLIENT-1968
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1968
> Project: HttpComponents HttpClient
> Issue Type: Bug
>Affects Versions: 4.5.7
>Reporter: Jay Modi
>Priority: Major
> Attachments: rewrite_preserve_forward_slash.diff
>
>
> URIs that contain an encoded forward slash (%2F) are no longer preserved when
> the HTTP client executes. I came across this when upgrading from 4.5.2 to
> 4.5.7 and my requests that contained an encoded forward slash suddenly
> started failing. The appears to be due to decoding and re-encoding of the
> path that takes place in the URIUtils#rewriteURI method. I've attached a
> patch that restores the old behavior but if a URI contains two slashes in a
> row in addition to an encoded slash the encoded forward slash will be decoded.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1968) Encoded forward slashes are not preserved when rewriting URI
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767107#comment-16767107 ] Stas Gromov commented on HTTPCLIENT-1968: - I just want to make exactly what I want - execute HTTP request to the url http://host/parent//child/ I can't do it with 4.5.7. I have no chances. The only way (except fixing this bug) is to switch HTTP client or to stick with 4.5.6 forever. > Encoded forward slashes are not preserved when rewriting URI > > > Key: HTTPCLIENT-1968 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1968 > Project: HttpComponents HttpClient > Issue Type: Bug >Affects Versions: 4.5.7 >Reporter: Jay Modi >Priority: Major > Attachments: rewrite_preserve_forward_slash.diff > > > URIs that contain an encoded forward slash (%2F) are no longer preserved when > the HTTP client executes. I came across this when upgrading from 4.5.2 to > 4.5.7 and my requests that contained an encoded forward slash suddenly > started failing. The appears to be due to decoding and re-encoding of the > path that takes place in the URIUtils#rewriteURI method. I've attached a > patch that restores the old behavior but if a URI contains two slashes in a > row in addition to an encoded slash the encoded forward slash will be decoded. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1968) Encoded forward slashes are not preserved when rewriting URI
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767100#comment-16767100
]
Oleg Kalnichevski commented on HTTPCLIENT-1968:
---
{quote}which is completably another resource{quote}
No, it is not. You are just trying to push silliness from the server onto the
client side.
Oleg
> Encoded forward slashes are not preserved when rewriting URI
>
>
> Key: HTTPCLIENT-1968
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1968
> Project: HttpComponents HttpClient
> Issue Type: Bug
>Affects Versions: 4.5.7
>Reporter: Jay Modi
>Priority: Major
> Attachments: rewrite_preserve_forward_slash.diff
>
>
> URIs that contain an encoded forward slash (%2F) are no longer preserved when
> the HTTP client executes. I came across this when upgrading from 4.5.2 to
> 4.5.7 and my requests that contained an encoded forward slash suddenly
> started failing. The appears to be due to decoding and re-encoding of the
> path that takes place in the URIUtils#rewriteURI method. I've attached a
> patch that restores the old behavior but if a URI contains two slashes in a
> row in addition to an encoded slash the encoded forward slash will be decoded.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1968) Encoded forward slashes are not preserved when rewriting URI
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767065#comment-16767065 ] Stas Gromov edited comment on HTTPCLIENT-1968 at 2/13/19 11:20 AM: --- I'm in. I have troubles upgrading to 4.5.7 I have http resource http://host/parent//child/ pid is optional so request to http://host/parent//child/ is legal but 4.5.7 converts it to http://host/parent/child/ which is completably another resource was (Author: kullfar): I'm in. I have troubles upgrading to 4.5.7 I have http resource http://host/parent//child/ pid is optional so request to http://host/parent//child/ is legal but 4.5.7 converts it to http://host/parent/child/ which is completably another reource > Encoded forward slashes are not preserved when rewriting URI > > > Key: HTTPCLIENT-1968 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1968 > Project: HttpComponents HttpClient > Issue Type: Bug >Affects Versions: 4.5.7 >Reporter: Jay Modi >Priority: Major > Attachments: rewrite_preserve_forward_slash.diff > > > URIs that contain an encoded forward slash (%2F) are no longer preserved when > the HTTP client executes. I came across this when upgrading from 4.5.2 to > 4.5.7 and my requests that contained an encoded forward slash suddenly > started failing. The appears to be due to decoding and re-encoding of the > path that takes place in the URIUtils#rewriteURI method. I've attached a > patch that restores the old behavior but if a URI contains two slashes in a > row in addition to an encoded slash the encoded forward slash will be decoded. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1968) Encoded forward slashes are not preserved when rewriting URI
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767065#comment-16767065
]
Stas Gromov edited comment on HTTPCLIENT-1968 at 2/13/19 11:20 AM:
---
I'm in.
I have troubles upgrading to 4.5.7
I have http resource http://host/parent//child/
pid is optional
so request to http://host/parent//child/ is legal
but 4.5.7 converts it to
http://host/parent/child/
which is completably another reource
was (Author: kullfar):
I'm in.
I have troubles upgrading to 4.5.7
I have http resource [http://host/parent/]/child/\{cid}
pid is optional
so request to [http://host/parent//child/]{cid} is legal
but 4.5.7 converts it to
[http://host/parent/child/\|http://host/parent/child/]{cid}
which is completably another reource
> Encoded forward slashes are not preserved when rewriting URI
>
>
> Key: HTTPCLIENT-1968
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1968
> Project: HttpComponents HttpClient
> Issue Type: Bug
>Affects Versions: 4.5.7
>Reporter: Jay Modi
>Priority: Major
> Attachments: rewrite_preserve_forward_slash.diff
>
>
> URIs that contain an encoded forward slash (%2F) are no longer preserved when
> the HTTP client executes. I came across this when upgrading from 4.5.2 to
> 4.5.7 and my requests that contained an encoded forward slash suddenly
> started failing. The appears to be due to decoding and re-encoding of the
> path that takes place in the URIUtils#rewriteURI method. I've attached a
> patch that restores the old behavior but if a URI contains two slashes in a
> row in addition to an encoded slash the encoded forward slash will be decoded.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1968) Encoded forward slashes are not preserved when rewriting URI
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767065#comment-16767065
]
Stas Gromov commented on HTTPCLIENT-1968:
-
I'm in.
I have troubles upgrading to 4.5.7
I have http resource http://host/parent//child/\{cid}
pid is optional
so request to http://host/parent//child/\{cid} is legal
but 4.5.7 converts it to
http://host/parent/child/\{cid}
which is completably another reource
> Encoded forward slashes are not preserved when rewriting URI
>
>
> Key: HTTPCLIENT-1968
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1968
> Project: HttpComponents HttpClient
> Issue Type: Bug
>Affects Versions: 4.5.7
>Reporter: Jay Modi
>Priority: Major
> Attachments: rewrite_preserve_forward_slash.diff
>
>
> URIs that contain an encoded forward slash (%2F) are no longer preserved when
> the HTTP client executes. I came across this when upgrading from 4.5.2 to
> 4.5.7 and my requests that contained an encoded forward slash suddenly
> started failing. The appears to be due to decoding and re-encoding of the
> path that takes place in the URIUtils#rewriteURI method. I've attached a
> patch that restores the old behavior but if a URI contains two slashes in a
> row in addition to an encoded slash the encoded forward slash will be decoded.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1968) Encoded forward slashes are not preserved when rewriting URI
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767065#comment-16767065
]
Stas Gromov edited comment on HTTPCLIENT-1968 at 2/13/19 11:18 AM:
---
I'm in.
I have troubles upgrading to 4.5.7
I have http resource [http://host/parent/]/child/\{cid}
pid is optional
so request to [http://host/parent//child/]{cid} is legal
but 4.5.7 converts it to
[http://host/parent/child/\|http://host/parent/child/]{cid}
which is completably another reource
was (Author: kullfar):
I'm in.
I have troubles upgrading to 4.5.7
I have http resource http://host/parent//child/\{cid}
pid is optional
so request to http://host/parent//child/\{cid} is legal
but 4.5.7 converts it to
http://host/parent/child/\{cid}
which is completably another reource
> Encoded forward slashes are not preserved when rewriting URI
>
>
> Key: HTTPCLIENT-1968
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1968
> Project: HttpComponents HttpClient
> Issue Type: Bug
>Affects Versions: 4.5.7
>Reporter: Jay Modi
>Priority: Major
> Attachments: rewrite_preserve_forward_slash.diff
>
>
> URIs that contain an encoded forward slash (%2F) are no longer preserved when
> the HTTP client executes. I came across this when upgrading from 4.5.2 to
> 4.5.7 and my requests that contained an encoded forward slash suddenly
> started failing. The appears to be due to decoding and re-encoding of the
> path that takes place in the URIUtils#rewriteURI method. I've attached a
> patch that restores the old behavior but if a URI contains two slashes in a
> row in addition to an encoded slash the encoded forward slash will be decoded.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
Re: RFC 2616 Retry-After Support
Thank you for your kind reply Oleg.
Based on the Apache Http Client site, it seems that HttpClient 5.0 is
still in beta. What is a good way for me and/or my company to
contribute towards moving the project forward?
Thank you,
Elijah
On Tue, Feb 12, 2019 at 1:42 AM Oleg Kalnichevski wrote:
>
> On Mon, 2019-02-11 at 20:02 -0800, Elijah Zupancic wrote:
> > Summary
> >
> > There is no provision for handling the rfc2616 Retry-After header in
> > the ServiceUnavailableRetryStrategy or ConnectionBackoffStrategy
> > interfaces. This makes implementing a wait based on a response after
> > the server returns a 503 difficult.
> >
> > Long Form
> >
> > Hi Folks,
> >
> > I've been a user of HTTP Client for years and I want to thank all of
> > the developers for their hard work. This is a high quality project
> > and
> > I'm sure it requires a lot of work handling community engagement.
> >
> > I'm using HTTP Client to interface with an open source object store
> > called Manta (https://github.com/joyent/manta) via the Java SDK (also
> > open source: https://github.com/joyent/java-manta). Some users of
> > this
> > object store are sending large amounts of data into the object store
> > and pushing it to its limits. As a result the object store will
> > periodically return 503 Service Unavailable errors with a Retry-After
> > header that provides a hint to the client regarding how many seconds
> > to wait until it retries.
> >
> > When examining the
> > org.apache.http.client.ServiceUnavailableRetryStrategy, I see that
> > the
> > interface contract doesn't make a provision for getting at the
> > Retry-After header (see:
> > https://tools.ietf.org/html/rfc2616#section-14.37) because the
> > getRetryInterval() method doesn't take a HttpResponse parameter.
> >
> > As I understand the design, implementations of the
> > ServiceUnavailableRetryStrategy interface need to be thread-safe, so
> > storing the retry interface as parsed from the HTTP response header
> > when the retryRequest call is invoked, isn't really viable. I could
> > imagine a complex system using ThreadLocal instances to pull this
> > off,
> > but that is far from ideal.
> >
> > Looking at
> > org.apache.http.impl.execchain.ServiceUnavailableRetryExec:88:
> >
> > if (this.retryStrategy.retryRequest(response, c, context)
> > && RequestEntityProxy.isRepeatable(request)) {
> > response.close();
> > final long nextInterval = this.retryStrategy.getRetryInterval();
> > if (nextInterval > 0) {
> > try {
> > this.log.trace("Wait for " + nextInterval);
> > Thread.sleep(nextInterval);
> > } catch (final InterruptedException e) {
> > Thread.currentThread().interrupt();
> > throw new InterruptedIOException();
> > }
> > }
> >
> > One alternative approach, I considered was doing the Thread.sleep()
> > call within the retryRequest() call, but I see that every response is
> > filtered through this code path when a
> > ServiceUnavailableRetryStrategy
> > is assigned and this feels like an abuse of the API contract.
> > Additionally, RequestEntityProxy.isRepeatable() is scoped within the
> > default package scope, so I can't reuse that code path to see if the
> > request is repeatable and I would have to resort to reflection to
> > accomplish the same thing.
> >
> > I also took a look at the
> > org.apache.http.client.ConnectionBackoffStrategy class, but it makes
> > no provision for the total time to backoff but rather adjusts the
> > size
> > of the connection pool (at least that is my understanding).
> >
> > I've been wracking my brain trying to come up with a solution that
> > will preserve API compatibility, but honestly it is hard to do
> > without
> > introducing a wart into the design.
> >
> > One of the less bad options, I considered was adding a method to the
> > ServiceUnavailableRetryStrategy interface:
> >
> > /**
> > * @param response the response from the target server
> > * @return The interval between the subsequent auto-retries.
> > */
> > long getRetryInterval(HttpResponse response);
> >
> > And modify the previously mentioned block as so:
> >
> > if (this.retryStrategy.retryRequest(response, c, context)
> > && RequestEntityProxy.isRepeatable(request)) {
> > response.close();
> > final long nextInterval = this.retryStrategy.getRetryInterval() >
> > 0 ?
> >this.retryStrategy.getRetryInterval() :
> > this.retryStrategy.getRetryInterval(response);
> > if (nextInterval > 0) {
> > try {
> > this.log.trace("Wait for " + nextInterval);
> > Thread.sleep(nextInterval);
> > } catch (final InterruptedException e) {
> > Thread.currentThread().interrupt();
> > throw new InterruptedIOException();
> > }
> > }
> >
> > This implementation would require careful documentation in the
> > interface.
> >
> > If anyone else has alternative suggestions or feedba
Re: RFC 2616 Retry-After Support
On Tue, 2019-02-12 at 22:35 -0800, Elijah Zupancic wrote:
> Thank you for your kind reply Oleg.
>
> Based on the Apache Http Client site, it seems that HttpClient 5.0 is
> still in beta.
We are not yet ready to freeze 5.0 APIs but otherwise what difference
does that make?
> What is a good way for me and/or my company to
> contribute towards moving the project forward? I'm sure this is
> written down somewhere, but I haven't found it.
>
That very much depends on your personal and your company's objectives.
There are tons of things in HttpComponents that could benefit from
extra attention. However familiarity with HC 5.0 is almost certainly a
prerequisite to any meaningful involvement in the project at this
point.
Cheers
Oleg
> Thank you,
> Elijah
>
> On Tue, Feb 12, 2019 at 1:42 AM Oleg Kalnichevski
> wrote:
> >
> > On Mon, 2019-02-11 at 20:02 -0800, Elijah Zupancic wrote:
> > > Summary
> > >
> > > There is no provision for handling the rfc2616 Retry-After header
> > > in
> > > the ServiceUnavailableRetryStrategy or ConnectionBackoffStrategy
> > > interfaces. This makes implementing a wait based on a response
> > > after
> > > the server returns a 503 difficult.
> > >
> > > Long Form
> > >
> > > Hi Folks,
> > >
> > > I've been a user of HTTP Client for years and I want to thank all
> > > of
> > > the developers for their hard work. This is a high quality
> > > project
> > > and
> > > I'm sure it requires a lot of work handling community engagement.
> > >
> > > I'm using HTTP Client to interface with an open source object
> > > store
> > > called Manta (https://github.com/joyent/manta) via the Java SDK
> > > (also
> > > open source: https://github.com/joyent/java-manta). Some users of
> > > this
> > > object store are sending large amounts of data into the object
> > > store
> > > and pushing it to its limits. As a result the object store will
> > > periodically return 503 Service Unavailable errors with a Retry-
> > > After
> > > header that provides a hint to the client regarding how many
> > > seconds
> > > to wait until it retries.
> > >
> > > When examining the
> > > org.apache.http.client.ServiceUnavailableRetryStrategy, I see
> > > that
> > > the
> > > interface contract doesn't make a provision for getting at the
> > > Retry-After header (see:
> > > https://tools.ietf.org/html/rfc2616#section-14.37) because the
> > > getRetryInterval() method doesn't take a HttpResponse parameter.
> > >
> > > As I understand the design, implementations of the
> > > ServiceUnavailableRetryStrategy interface need to be thread-safe,
> > > so
> > > storing the retry interface as parsed from the HTTP response
> > > header
> > > when the retryRequest call is invoked, isn't really viable. I
> > > could
> > > imagine a complex system using ThreadLocal instances to pull this
> > > off,
> > > but that is far from ideal.
> > >
> > > Looking at
> > > org.apache.http.impl.execchain.ServiceUnavailableRetryExec:88:
> > >
> > > if (this.retryStrategy.retryRequest(response, c, context)
> > > && RequestEntityProxy.isRepeatable(request)) {
> > > response.close();
> > > final long nextInterval =
> > > this.retryStrategy.getRetryInterval();
> > > if (nextInterval > 0) {
> > > try {
> > > this.log.trace("Wait for " + nextInterval);
> > > Thread.sleep(nextInterval);
> > > } catch (final InterruptedException e) {
> > > Thread.currentThread().interrupt();
> > > throw new InterruptedIOException();
> > > }
> > > }
> > >
> > > One alternative approach, I considered was doing the
> > > Thread.sleep()
> > > call within the retryRequest() call, but I see that every
> > > response is
> > > filtered through this code path when a
> > > ServiceUnavailableRetryStrategy
> > > is assigned and this feels like an abuse of the API contract.
> > > Additionally, RequestEntityProxy.isRepeatable() is scoped within
> > > the
> > > default package scope, so I can't reuse that code path to see if
> > > the
> > > request is repeatable and I would have to resort to reflection to
> > > accomplish the same thing.
> > >
> > > I also took a look at the
> > > org.apache.http.client.ConnectionBackoffStrategy class, but it
> > > makes
> > > no provision for the total time to backoff but rather adjusts the
> > > size
> > > of the connection pool (at least that is my understanding).
> > >
> > > I've been wracking my brain trying to come up with a solution
> > > that
> > > will preserve API compatibility, but honestly it is hard to do
> > > without
> > > introducing a wart into the design.
> > >
> > > One of the less bad options, I considered was adding a method to
> > > the
> > > ServiceUnavailableRetryStrategy interface:
> > >
> > > /**
> > > * @param response the response from the target server
> > > * @return The interval between the subsequent auto-retries.
> > > */
> > > long getRetryInterval(HttpResponse response);
> > >
[jira] [Commented] (HTTPASYNC-148) ResponseContentEncoding not working with HttpAsyncClient
[
https://issues.apache.org/jira/browse/HTTPASYNC-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16766910#comment-16766910
]
Oleg Kalnichevski commented on HTTPASYNC-148:
-
[~slisaasquatch] There are three options
# Buffer content in memory or in a file and then use blocking
{{GZIPInputStream}} to decompress it
# Implement non-blocking {{HttpAsyncResponseConsumer}} that can decompress
content while it is being streamed from the underlying non-blocking HTTP
connection
# Use blocking HttpClient
Oleg
> ResponseContentEncoding not working with HttpAsyncClient
>
>
> Key: HTTPASYNC-148
> URL: https://issues.apache.org/jira/browse/HTTPASYNC-148
> Project: HttpComponents HttpAsyncClient
> Issue Type: Bug
>Affects Versions: 4.1.4
> Environment: Windows 10, Oracle JDK 1.8.0_161
>Reporter: Siqi Li
>Priority: Major
>
> Here's my code snippet:
> {code:java}
> import java.io.ByteArrayInputStream;
> import java.util.zip.GZIPInputStream;
> import org.apache.commons.io.IOUtils;
> import org.apache.http.HttpResponse;
> import org.apache.http.client.methods.HttpGet;
> import org.apache.http.client.protocol.RequestAcceptEncoding;
> import org.apache.http.client.protocol.ResponseContentEncoding;
> import org.apache.http.impl.nio.client.CloseableHttpAsyncClient;
> import org.apache.http.impl.nio.client.HttpAsyncClients;
> import org.apache.http.util.EntityUtils;
> public class Issue20190211 {
> public static void main(String[] args) throws Exception {
> try (CloseableHttpAsyncClient client = HttpAsyncClients.custom()
> .addInterceptorFirst(new
> RequestAcceptEncoding())
> .addInterceptorFirst(new
> ResponseContentEncoding())
> .build()) {
> client.start();
> final HttpResponse response = client.execute(
> new HttpGet("http://example.com";),
> null).get();
> final byte[] respBytes =
> EntityUtils.toByteArray(response.getEntity());
> System.out.println(new String(respBytes, "UTF-8")); //
> Prints gibberish
> final String decompressed = IOUtils.toString(
> new GZIPInputStream(new
> ByteArrayInputStream(respBytes)), "UTF-8");
> System.out.println(decompressed); // This gives me the
> correct result
> }
> }
> }
> {code}
> What this looks like to me is that the HttpRequestInterceptor is working,
> since the server is responding with gzipped content, but the
> HttpResponseInterceptor is not, since I still have to manually decompress the
> content.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
