Introduce the notion of a default SessionProtocol

[jrhee17]

Motivation:

It has been suggested that SessionProtocol.UNDEFINED be avoided at #6060 (comment), and a default SessionProtocol for clients is introduced.

A client can now be created without the user explicitly providing a SessionProtocol. By default SessionProtocol.HTTP will be used. For clients that are created with a String, users will be able to use the default SessionProtocol via scheme relative URIs as defined in the following rfc.

WebClient.builder("//armeria.dev").build()
WebClient.builder(new URI(null, "armeria.dev", null, null)).build()
WebClient.builder(Endpoint.of("armeria.dev")
WebClient.builder(Endpoint.of("armeria.dev"), "/").build()
WebClient.of().blocking().get("//armeria.dev/hello")

One point to note is that RequestTarget may be parsed different depending on whether the input is a path, or a uri.
In the context of a path, //my-path is a completely valid path whereas in the context of a URI, //my-path will be a uri with authority my-path.
In order to address this, DefaultRequestTarget#forClientPath has been introduced.

Possibly breaking behavior is that requests cannot be made using a path starting with //.

Modifications:

• Added factory methods to use the default SessionProtocol as defined by SessionProtocolUtil#defaultSessionProtocol.
• Added scheme-relative URI handling logic when parsing the authority in RequestTarget#forClient
• Added RequestTarget#forClientPath and modified existing callers to use the new API when applicable

Result:

• Users may create a client without explicitly specifying the SessionProtocol

[github-actions]

🔍 Build Scan® (commit: 7ad5386)

Job name	Status	Build Scan®
build-ubicloud-standard-16-jdk-8	✅	https://ge.armeria.dev/s/btgnb2mgxo4sc
build-ubicloud-standard-16-jdk-21-snapshot-blockhound	✅	https://ge.armeria.dev/s/hlcag75vez2ry
build-ubicloud-standard-16-jdk-17-min-java-17-coverage	✅	https://ge.armeria.dev/s/khkz25w65agqy
build-ubicloud-standard-16-jdk-17-min-java-11	✅	https://ge.armeria.dev/s/fsmotq2fwh2ia
build-ubicloud-standard-16-jdk-17-leak	✅	https://ge.armeria.dev/s/6y67sewhsgx4w
build-ubicloud-standard-16-jdk-11	✅	https://ge.armeria.dev/s/o7uq2trb7tg7y
build-macos-latest-jdk-21	✅	https://ge.armeria.dev/s/izc7ol3xqjrqk

[codecov]

Codecov Report

Attention: Patch coverage is 84.09091% with 14 lines in your changes missing coverage. Please review.

Project coverage is 74.56%. Comparing base (8150425) to head (7ad5386).
Report is 52 commits behind head on main.

Files with missing lines	Patch %	Lines
...rp/armeria/internal/common/RequestTargetCache.java	66.66%	0 Missing and 3 partials ⚠️
.../linecorp/armeria/client/thrift/ThriftClients.java	57.14%	3 Missing ⚠️
...p/armeria/internal/client/SessionProtocolUtil.java	71.42%	2 Missing ⚠️
...orp/armeria/client/eureka/EurekaEndpointGroup.java	0.00%	2 Missing ⚠️
.../armeria/server/eureka/EurekaUpdatingListener.java	0.00%	2 Missing ⚠️
.../com/linecorp/armeria/client/grpc/GrpcClients.java	50.00%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #6128      +/-   ##
============================================
+ Coverage     74.46%   74.56%   +0.09%     
- Complexity    22234    22410     +176     
============================================
  Files          1963     1970       +7     
  Lines         82437    82838     +401     
  Branches      10764    10777      +13     
============================================
+ Hits          61385    61765     +380     
- Misses        15918    15937      +19     
- Partials       5134     5136       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[minwoox]

WebClient.builder("//armeria.dev").build()

This looks a bit odd. 😓
IIRC, we referred to how curl behaves when the scheme is omitted.
curl only accepts it when the URL starts directly with the hostname:

curl //www.google.com
curl: (3) URL rejected: No host part in the URL

Should we follow the same behavior for consistency?

[jrhee17]

Should we follow the same behavior for consistency?

I don't think supporting //google.com means we won't support google.com eventually.

1. The URI API does not detect hostnames the same way as curl does

final URI uri = URI.create("google.com");
System.out.println(uri.getAuthority()); // null
System.out.println(uri.getPath()); // google.com

Removing URI validation within our code-base could help with this issue.

2. The path API may become ambiguous, we may need to change the behavior of the default WebClient

WebClient.of(google.com).get(apple.com)
// should this be http://google.com/apple.com?
// currently, this should throw an exception

If there is a consensus on these cases, I can add further modifications to also support google.com the same way as curl does.

[minwoox]

The URI API does not detect hostnames the same way as curl does

I see, I missed that point.
If so, what do you think about raising an exception as-is when the uri is specified without a scheme, and only applying the default session protocol for methods that accept the session protocol separately?
For example: WebClient.builder(Endpoint.of("armeria.dev"))

I’m asking because I'm worried about the scenarios you mentioned in the description. It might give confusion to users so trying to find if we have another option.

[minwoox]

/cc @line/dx

[jrhee17]

I still maintain that it seems odd that WebClient.of(EndpointGroup) works whereas WebClient.of("google.com") doesn't. Especially given that this API is on the main path of users who use Armeria.

I’m asking because I'm worried about the scenarios you mentioned in the description. It might give confusion to users so trying to find if we have another option.
Possibly breaking behavior is that requests cannot be made using a path starting with //.

On second thought, encoding the second / or omitting it entirely may make more sense.
Let me try to eliminate the cause of breaking change, as well as try to follow curl behavior then.

[jrhee17]

Will handle this some other time