Is there an existing issue for this?

• I have searched the existing issues

Kong version ($ kong version)

Kong 3.8.0 and above

Current Behavior

Noticed it after 3.8.0 added the upstream Via header in 575284f

The Via header sent by Kong cannot be parsed according to RFC7230 Section 5.7.1.

For example, the parser used by .NET 8 System.Net.Http.Headers.HttpHeaders.Add (source) fails validation.

Example:

Testing Via header: '1.1 Kong/3.9.1'
✗ Error adding Via header: The format of value '1.1 Kong/3.9.1' is invalid.
Trace:
   at System.Net.Http.Headers.HttpHeaderParser.ParseValue(String value, Object storeValue, Int32& index)
   at System.Net.Http.Headers.HttpHeaders.ParseAndAddValue(HeaderDescriptor descriptor, HeaderStoreItemInfo info, String value)
   at System.Net.Http.Headers.HttpHeaders.Add(HeaderDescriptor descriptor, String value)
   at Program.<Main>$(String[] args) in /mypath/testnetheaders/ViaHeaderTest/Program.cs:line 29

Expected Behavior

A Via header value that complies with RFC7230 Section 5.7.1 like other proxies send.

Steps To Reproduce

• Upgrade to Kong 3.8.0 or above
• Set a route to an echo service
• Check the Via HTTP header added by Kong

Anything else?

It seems the problem is in using meta._SERVER_TOKENS directly as the received-by portion of the Viaheader, since the forward slash is not a valid tchar according to the RFC7230 Appendix B.

Sample valid options:

1. Sending a lowercase "kong" pseudonym as received-by and the server tokens in the comment section

1.1 kong (Kong/3.9.1)

2. Replacing the forward slash with a dash in the server tokens

1.1 Kong-3.8.0

It seems the first option is the one chosen by most proxies.

Examples from other proxies:

1.0 proxy1.example.com (Apache/2.4.54)

1.1 proxy3.example.com (squid/3.1)

1.1 abcdefgh.cloudfront.net (CloudFront)