[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=16819278#comment-16819278 ] Matt Nelson commented on HTTPCLIENT-1968: - Logged issue HTTPCLIENT-1984 and issued pr https://github.com/apache/httpcomponents-client/pull/144 to address the copy constructor. > 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 > Fix For: 4.5.8, 5.0 Beta4 > > Attachments: rewrite_preserve_forward_slash.diff > > Time Spent: 3.5h > Remaining Estimate: 0h > > 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] [Updated] (HTTPCLIENT-1984) Add normalize URI to RequestConfig copy constructor
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Nelson updated HTTPCLIENT-1984: Summary: Add normalize URI to RequestConfig copy constructor (was: Add normalized URI to RequestConfig copy constructor) > Add normalize URI to RequestConfig copy constructor > --- > > Key: HTTPCLIENT-1984 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1984 > Project: HttpComponents HttpClient > Issue Type: Bug >Affects Versions: 4.5.8 >Reporter: Matt Nelson >Priority: Major > > The request URI normalization configuration introduced via HTTPCLIENT-1968 > missed adding the new field to the RequestConfig copy constructor -- 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] [Created] (HTTPCLIENT-1984) Add normalized URI to RequestConfig copy constructor
Matt Nelson created HTTPCLIENT-1984: --- Summary: Add normalized URI to RequestConfig copy constructor Key: HTTPCLIENT-1984 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1984 Project: HttpComponents HttpClient Issue Type: Bug Affects Versions: 4.5.8 Reporter: Matt Nelson The request URI normalization configuration introduced via HTTPCLIENT-1968 missed adding the new field to the RequestConfig copy constructor -- 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=16815848#comment-16815848 ] Matt Nelson commented on HTTPCLIENT-1968: - Attempting to validate this change for my use case. The copy method on RequestConfig was not updated for normalizeUri. I built a local snapshot with that additional change and was able to verify. https://github.com/apache/httpcomponents-client/pull/136 https://github.com/apache/httpcomponents-client/blob/4.5.8/httpclient/src/main/java/org/apache/http/client/config/RequestConfig.java#L384 > 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 > Fix For: 4.5.8, 5.0 Beta4 > > Attachments: rewrite_preserve_forward_slash.diff > > Time Spent: 3.5h > Remaining Estimate: 0h > > 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=16771439#comment-16771439
]
Matt Nelson commented on HTTPCLIENT-1968:
-
{quote}
The conversation here is only about slashes. However any encoding breaks (in
our case encoded colons).
{quote}
Adding another use case where encoded commas in the path are treated
differently based on the build flow. Construction vs fluent builder.
{code}
@Test
public void uribuilder() throws URISyntaxException {
final String rawURI =
"http://localhost/service/before1%2Cafter1,before2%2Cafter2?qp1=1=2;;
System.out.println("raw uri");
System.out.println(rawURI);
final URI uri = new URIBuilder(rawURI).build();
System.out.println("builder from URI");
System.out.println(uri);
final URI fluentURI =
new URIBuilder()
.setHost(uri.getHost())
.setPath(uri.getPath())
.setCustomQuery(uri.getQuery())
.setScheme(uri.getScheme())
.build();
System.out.println("fluent builder using setQuery");
System.out.println(fluentURI);
final URIBuilder urib =
new URIBuilder()
.setHost(uri.getHost())
.setPath(uri.getPath())
.setCustomQuery(uri.getQuery())
.setScheme(uri.getScheme());
Arrays.asList(uri.getQuery().split("&")).stream()
.forEach(
q -> {
final String[] value = q.split("=");
urib.setParameter(value[0], value[1]);
});
System.out.println("fluent builder using setParameter");
System.out.println(urib.build());
}
{code}
{noformat}
raw uri
http://localhost/service/before1%2Cafter1,before2%2Cafter2?qp1=1=2
builder from URI
http://localhost/service/before1%2Cafter1,before2%2Cafter2?qp1=1=2
fluent builder using setQuery
http://localhost/service/before1,after1,before2,after2?qp1=1=2
fluent builder using setParameter
http://localhost/service/before1,after1,before2,after2?qp1=1=2
{noformat}
> 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
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> 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] (HTTPCORE-469) Use ReentrantReadWriteLock in AbstractConnPool
[
https://issues.apache.org/jira/browse/HTTPCORE-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16054222#comment-16054222
]
Matt Nelson commented on HTTPCORE-469:
--
I'm ok with waiting for the lockless connection pool. I have not noticed any
performance issues with the current implementation for my use cases, but
thought I'd put out the recommendation for the lock refactoring.
> Use ReentrantReadWriteLock in AbstractConnPool
> --
>
> Key: HTTPCORE-469
> URL: https://issues.apache.org/jira/browse/HTTPCORE-469
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore
>Reporter: Matt Nelson
>Assignee: Oleg Kalnichevski
>Priority: Minor
> Labels: stuck, volunteers-wanted
> Fix For: Future
>
>
> AbstractConnPool is currently using a {{ReentrantLock}} which has to lock for
> read and write operations. Switching to {{ReentrantReadWriteLock}}[1] and
> read locks for the stats/getters methods would reduce the possibility for
> instrumentation[1] to cause contention. Another option would be
> {{StampedLock}}[3] if the compile target is 1.8.
> [1]
> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html
> [2]
> https://github.com/dropwizard/metrics/blob/v3.2.2/metrics-httpclient/src/main/java/com/codahale/metrics/httpclient/InstrumentedHttpClientConnectionManager.java#L63-L95
> [3]
> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/StampedLock.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCORE-469) Use ReentrantReadWriteLock in AbstractConnPool
Matt Nelson created HTTPCORE-469:
Summary: Use ReentrantReadWriteLock in AbstractConnPool
Key: HTTPCORE-469
URL: https://issues.apache.org/jira/browse/HTTPCORE-469
Project: HttpComponents HttpCore
Issue Type: Improvement
Components: HttpCore
Reporter: Matt Nelson
Priority: Minor
AbstractConnPool is currently using a {{ReentrantLock}} which has to lock for
read and write operations. Switching to {{ReentrantReadWriteLock}}[1] and read
locks for the stats/getters methods would reduce the possibility for
instrumentation[1] to cause contention. Another option would be
{{StampedLock}}[3] if the compile target is 1.8.
[1]
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html
[2]
https://github.com/dropwizard/metrics/blob/v3.2.2/metrics-httpclient/src/main/java/com/codahale/metrics/httpclient/InstrumentedHttpClientConnectionManager.java#L63-L95
[3]
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/StampedLock.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
