GoRouter: confusing "http2" logs when HTTP/2 routing is disabled by an operator #217
Comments
|
We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story. The labels on this github issue will be updated when the story is started. |
|
Related to #200 |
mkocher
pushed a commit
to cloudfoundry/gorouter
that referenced
this issue
Sep 9, 2021
- When routes are registered and HTTP/2 is disabled, persist the protocol for endpoints as 'http1', even if the message has protocol 'http2'. - It was confusing that the route registry and gorouter logs would show protocol 'http2', even if it would really use HTTP/1.1 when communicating with backends. - Enabling HTTP/2 will require restarting the gorouter, so the route registry will be regenerated with 'http2'. [cloudfoundry/routing-release#217] [cloudfoundry/routing-release#200]
5 tasks
geofffranks
pushed a commit
to cloudfoundry/gorouter
that referenced
this issue
Sep 30, 2021
- When routes are registered and HTTP/2 is disabled, persist the protocol for endpoints as 'http1', even if the message has protocol 'http2'. - It was confusing that the route registry and gorouter logs would show protocol 'http2', even if it would really use HTTP/1.1 when communicating with backends. - Enabling HTTP/2 will require restarting the gorouter, so the route registry will be regenerated with 'http2'. [cloudfoundry/routing-release#217] [cloudfoundry/routing-release#200]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue
GoRouter might generate confusing "http2" logs when HTTP/2 routing is disabled by an operator.
Affected Versions
0.223.0
Context
Given open source options related to the new HTTP/2 feature, a developer could set a route to use HTTP/2 in CloudController, but have HTTP/2 disabled on GoRouter by a platform operator. The route would still have its protocol set to "http2" even though GoRouter would never actually communicate with the destination via HTTP/2. Even though in this case gorouter would take the right actions, the route destination would still show up in the route table and in logs as as "http2". This could confuse debugging.
Steps to Reproduce
enable_http2flag in routing-release to be false.Expected result
Requests are hitting the app with HTTP/1.1 and logs and route info reflect that.
Current result
Requests are hitting the app with HTTP/1.1 but logs and route info says
"protocol": "http2".Possible Fix
Always set a route destination protocol to "http1" if http2 is disabled at the GoRouter level?
cc @moleske @ameowlia
The text was updated successfully, but these errors were encountered: