WebClient uses absolute request URI in requests when used via the proxy and host is listed in the no_proxy

[istaveren]

Environment Details

• Helidon Version: 2.3.3 but also happens in 2.3.1
• Helidon SE
• JDK version: 11.0.12
• OS: Oracle linux
• Docker version (if applicable): 20.10.6

---

Problem Description

Looks similar to issue #2302

Helidon WebClient uses an absolute request URI rather than a relative one when submitting HTTP requests. Most of times this is not an issue, but there are some HTTP server implementation that are not able to deal with it.

For example, due to this issue using Helidon WebClient I'm not able to get an OAuth Token from Oracle Identity Cloud because my requests fail with a 404.

The requests issued by Helidon WebClient look like the following:

POST <idcs-host>/oauth2/v1/token HTTP/1.1
Accept: text/plain
Accept: application/json
Content-Type: application/x-www-form-urlencoded
host: <idcs-host>

While instead the expected format should be:

POST /oauth2/v1/token HTTP/1.1
Accept: text/plain
Accept: application/json
Content-Type: application/x-www-form-urlencoded
host: <idcs-host>

Section 5 of RFC 2116 is a bit ambiguous about the Request-URI format responsibilities:

To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.

To avoid such kind of issues, the Helidon WebClient should used absolute URI only when effectively required, or make this behavior configurable.

Steps to reproduce

Add a proxy to your configuration:

client:
 proxy:
   host: someproxy.url
   port: 80
   no-proxy:
     - localhost
     - .oc9qadev.com

It only seems to happen with idcs token request.

Here is a detailed trace.

Without proxy it sends:

         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 50 4f 53 54 20 2f 6f 61 75 74 68 32 2f 76 31 2f |POST /oauth2/v1/|
|00000010| 74 6f 6b 65 6e 20 48 54 54 50 2f 31 2e 31 0d 0a |token HTTP/1.1..|
|00000020| 41 75 74 68 6f 72 69 7a 61 74 69 6f 6e 3a 20 62 |Authorization: b|
|00000030| 61 73 69 63 20 51 55 6c 42 51 31 4e 66 51 31 68 |asic QUlBQ1NfQ1h|

With proxy configures it sends:

         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 50 4f 53 54 20 68 74 74 70 73 3a 2f 2f 69 64 63 |POST https://idc|
|00000010| 73 2d 65 61 39 36 34 31 30 63 64 31 65 38 34 33 |s-ea96410cd1e843|
|00000020| 66 63 62 32 35 34 61 34 35 35 33 37 63 62 31 37 |fcb254a45537cb17|
|00000030| 35 63 2e 69 64 65 6e 74 69 74 79 2e 63 39 64 65 |5c.identity.c9de|
|00000040| 76 32 2e 6f 63 39 71 61 64 65 76 2e 63 6f 6d 3a |v2.oc9qadev.com:|
|00000050| 34 34 33 2f 6f 61 75 74 68 32 2f 76 31 2f 74 6f |443/oauth2/v1/to|
|00000060| 6b 65 6e 20 48 54 54 50 2f 31 2e 31 0d 0a 41 75 |ken HTTP/1.1..Au|
|00000070| 74 68 6f 72 69 7a 61 74 69 6f 6e 3a 20 62 61 73 |thorization: bas|
|00000080| 69 63 20 51 55 6c 42 51 31 4e 66 51 31 68 66 51 |ic QUlBQ1NfQ1hfQ|

[spericas]

@istaveren This seems almost identical to #2302. I guess what you're stating here is that the fix for that original issue is somehow incomplete. It should definitely be in 2.3.X. It could be that the original fix does not take into account the no-proxy list.

[istaveren]

Yes, correct. I think the original fix is incomplete or the same problem happens when a proxy is used.

[spericas]

PR #3442

[spericas]

Should be fixed by PR #3442. Reopen if you find any problems.