[GitHub] [httpcomponents-core] arturobernalg commented on a diff in pull request #418: HTTPCORE-756 - Deprecation of userInfo in Compliance with RFC 9110

2023-08-25 Thread via GitHub
arturobernalg commented on code in PR #418: URL: https://github.com/apache/httpcomponents-core/pull/418#discussion_r1305308816 ## httpcore5/src/main/java/org/apache/hc/core5/net/URIBuilder.java: ## @@ -156,7 +155,7 @@ public URIBuilder setAuthority(final NamedEndpoint authorit

[GitHub] [httpcomponents-core] arturobernalg opened a new pull request, #419: Refactor testConcurrentOperations to use AtomicBooleans for outcome v…

2023-08-25 Thread via GitHub
arturobernalg opened a new pull request, #419: URL: https://github.com/apache/httpcomponents-core/pull/419 Refactor `testConcurrentOperations` to use `AtomicBooleans` for outcome verification, enhancing test determinism and reducing exception unpredictability. -- This is an automated mes

[GitHub] [httpcomponents-core] ok2c commented on pull request #418: HTTPCORE-756 - Deprecation of userInfo in Compliance with RFC 9110

2023-08-25 Thread via GitHub
ok2c commented on PR #418: URL: https://github.com/apache/httpcomponents-core/pull/418#issuecomment-1693338496 @arturobernalg I am fine with all the proposed changes but I personally think that `URIBuilder` should still support user info as it is not meant to be strictly `http`/`https` spe

[GitHub] [httpcomponents-core] arturobernalg commented on pull request #419: Refactor testConcurrentOperations to use AtomicBooleans for outcome v…

2023-08-25 Thread via GitHub
arturobernalg commented on PR #419: URL: https://github.com/apache/httpcomponents-core/pull/419#issuecomment-1693359992 > @arturobernalg Interesting. Future callbacks are deterministic but the future itself is not? @ok2c With `` AtomicBoolean` ensures we can deterministically t

[GitHub] [httpcomponents-core] arturobernalg commented on pull request #418: HTTPCORE-756 - Deprecation of userInfo in Compliance with RFC 9110

2023-08-25 Thread via GitHub
arturobernalg commented on PR #418: URL: https://github.com/apache/httpcomponents-core/pull/418#issuecomment-1693409507 > @arturobernalg I am fine with all the proposed changes but I personally think that `URIBuilder` should still support user info as it is not meant to be strictly `http`/

[GitHub] [httpcomponents-core] michael-o commented on pull request #418: HTTPCORE-756 - Deprecation of userInfo in Compliance with RFC 9110

2023-08-25 Thread via GitHub
michael-o commented on PR #418: URL: https://github.com/apache/httpcomponents-core/pull/418#issuecomment-1693435870 > > @arturobernalg I am fine with all the proposed changes but I personally think that `URIBuilder` should still support user info as it is not meant to be strictly `http`/`h

[GitHub] [httpcomponents-core] dependabot[bot] opened a new pull request, #420: Bump io.reactivex.rxjava3:rxjava from 3.1.6 to 3.1.7

2023-08-25 Thread via GitHub
dependabot[bot] opened a new pull request, #420: URL: https://github.com/apache/httpcomponents-core/pull/420 Bumps [io.reactivex.rxjava3:rxjava](https://github.com/ReactiveX/RxJava) from 3.1.6 to 3.1.7. Release notes Sourced from https://github.com/ReactiveX/RxJava/releases";>io.re

[GitHub] [httpcomponents-core] bpitman opened a new pull request, #421: Support InetAddress throughout request execution

2023-08-25 Thread via GitHub
bpitman opened a new pull request, #421: URL: https://github.com/apache/httpcomponents-core/pull/421 Note that this patch is probably incomplete - it does not break existing tests, but no tests were added nor updated to verify the new code. We have a need to set the InetAddress for a

[GitHub] [httpcomponents-core] ok2c commented on pull request #419: Refactor testConcurrentOperations to use AtomicBooleans for outcome v…

2023-08-25 Thread via GitHub
ok2c commented on PR #419: URL: https://github.com/apache/httpcomponents-core/pull/419#issuecomment-1693665913 > Maybe I'm wrong but BasicFuture operations are inherently non-deterministic @arturobernalg It was not my intent when I initially built `BasicFuture` but this is likely how

[GitHub] [httpcomponents-core] arturobernalg merged pull request #419: Refactor testConcurrentOperations to use AtomicBooleans for outcome v…

2023-08-25 Thread via GitHub
arturobernalg merged PR #419: URL: https://github.com/apache/httpcomponents-core/pull/419 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr..

[GitHub] [httpcomponents-core] bpitman commented on pull request #421: Support InetAddress throughout request execution

2023-08-25 Thread via GitHub
bpitman commented on PR #421: URL: https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693678024 I ran locally with `-Djapicmp.skip=true` (needed with `package`, but not `test`). Is there a mechanism for documenting known changes to the api? -- This is an automated mess

[GitHub] [httpcomponents-core] ok2c commented on pull request #421: Support InetAddress throughout request execution

2023-08-25 Thread via GitHub
ok2c commented on PR #421: URL: https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693692150 @bpitman What is exactly the intent of this change? Why do you think you need an `InetAddress` at the request level? It is completely unclear from the description of the PR or fro

[GitHub] [httpcomponents-core] bpitman commented on pull request #421: Support InetAddress throughout request execution

2023-08-25 Thread via GitHub
bpitman commented on PR #421: URL: https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693695500 See initial comment: ``` We have a need to set the InetAddress for a request - the ip tells us where to connect and the hostname is needed for ssl verification. ```

[GitHub] [httpcomponents-core] bpitman commented on pull request #421: Support InetAddress throughout request execution

2023-08-25 Thread via GitHub
bpitman commented on PR #421: URL: https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693712807 Example data for a request: ``` { "state": "RUNNING", "status": "UP", "name": "upload", "hostname": "192.168.30.10", "ip": "192.168.30.10", "s

[GitHub] [httpcomponents-core] ok2c commented on pull request #421: Support InetAddress throughout request execution

2023-08-25 Thread via GitHub
ok2c commented on PR #421: URL: https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693714227 > We have a need to set the InetAddress for a request - the ip tells us where to connect and the hostname is needed for ssl verification. @bpitman This makes no sense at the

[GitHub] [httpcomponents-core] ok2c commented on pull request #421: Support InetAddress throughout request execution

2023-08-25 Thread via GitHub
ok2c commented on PR #421: URL: https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693731633 @bpitman In your particular case you do not even need any custom code. All you need to do is to set up the connection route correctly. ``` final HttpHost target = new HttpHos

[GitHub] [httpcomponents-core] bpitman commented on pull request #421: Support InetAddress throughout request execution

2023-08-25 Thread via GitHub
bpitman commented on PR #421: URL: https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693765595 It would have saved me a lot of time if this had worked. Having InetAddress in HttpHost made it seem like it supported my needs right out of the box. Look at my changes to se

[GitHub] [httpcomponents-core] bpitman commented on pull request #421: Support InetAddress throughout request execution

2023-08-25 Thread via GitHub
bpitman commented on PR #421: URL: https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693771484 To be clear, I'm using httpcore5, not httpclient5. The client looks like non-blocking wrappers around around blocking code - though, maybe just poor examples? We can't expect

[GitHub] [httpcomponents-core] ok2c commented on pull request #421: Support InetAddress throughout request execution

2023-08-25 Thread via GitHub
ok2c commented on PR #421: URL: https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693869120 > To be clear, I'm using httpcore5, not httpclient5. @bpitman You should have started off by saying that. HttpClient has a by far more complex and sophisticated connection m

[GitHub] [httpcomponents-core] bpitman commented on pull request #421: Support InetAddress throughout request execution

2023-08-25 Thread via GitHub
bpitman commented on PR #421: URL: https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1694006616 Messing around with client examples. The target ends up wrong if HttpHost is part of the request object, but works if passed in directly to client.execute() - as you suggested

[GitHub] [httpcomponents-core] bpitman commented on pull request #421: Support InetAddress throughout request execution

2023-08-25 Thread via GitHub
bpitman commented on PR #421: URL: https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1694123536 The fixes in the pr address all of these use cases using core5 directly. client5 is still broken - it needs similar fixes (rebuild the HttpHost using address info that had bee

[GitHub] [httpcomponents-core] garydgregory commented on pull request #421: Support InetAddress throughout request execution

2023-08-25 Thread via GitHub
garydgregory commented on PR #421: URL: https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1694132384 Shouldn't we use builders instead of adding yet even more constructors? -- This is an automated message from the Apache Git Service. To respond to the message, please log

[GitHub] [httpcomponents-core] bpitman commented on pull request #421: Support InetAddress throughout request execution

2023-08-25 Thread via GitHub
bpitman commented on PR #421: URL: https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1694137687 Generally, yes. This doesn't look like a typical builder pattern, though. -- This is an automated message from the Apache Git Service. To respond to the message, please log o