Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Force http/1.1 for upgrade (Traefik v1) #6553

Merged
merged 7 commits into from
Mar 23, 2020
Merged

Conversation

juliens
Copy link
Member

@juliens juliens commented Mar 23, 2020

What does this PR do?

This PR force the use of http1.1 with the backend when the request is a Connection:Upgrade because Connection: Upgrade is not valid for http2.

Motivation

Some kubernetes api server refuse http2 during tls-alpn (like k3s) but some other just don't (like kind) and so, SPDY upgrade fails. This PR fixes this behavior.

Fixes #6527

More

- [ ] Added/updated tests
- [ ] Added/updated documentation

Copy link
Member

@ldez ldez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@jbdoumenjou jbdoumenjou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ldez ldez changed the title Force http/1.1 for upgrade Force http/1.1 for upgrade (Traefik v1) Mar 23, 2020
server/smart_roundtripper.go Show resolved Hide resolved
server/server.go Outdated Show resolved Hide resolved
@ldez ldez deleted the fix-spdy branch March 23, 2020 14:59
@joejulian
Copy link

Tested and validated. Thanks @juliens 👍

server.defaultForwardingRoundTripper = transport
server.defaultForwardingRoundTripper, err = newSmartRoundTripper(transport)
if err != nil {
log.Errorf("Failed to create HTTP transport: %v", err)
Copy link

@gpaul gpaul Mar 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really an error we can proceed on? That is unrelated to this PR (it has always just swallowed this error) but it seems strange that an HTTP proxy ignores an error in setting up its transport and proceeds without one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants