[lxcxjxhx]

What

Fix ConnectionUpgrade() in resp/header.go which was incorrectly checking for keep-alive instead of Upgrade in the Connection header.

Why

The function name and comment clearly state it should check for Connection: Upgrade, but the implementation was using bytestr.StrKeepAlive instead of bytestr.StrUpgrade.

This bug affects WebSocket support: when a response has Connection: Upgrade (as in WebSocket handshakes), ConnectionUpgrade() returns false, causing the code at line 204 to incorrectly set Transfer-Encoding: identity and close the connection.

Conversely, regular keep-alive responses would incorrectly trigger the upgrade path.

Changes

• resp/header.go: change bytestr.StrKeepAlive to bytestr.StrUpgrade in ConnectionUpgrade()

Testing

go test ./pkg/protocol/http1/resp/...

All existing tests pass. This is a one-line bug fix.

[CLAassistant]

All committers have signed the CLA.

[lxcxjxhx]

Rebased onto the current main so CI runs on today's toolchain.

The red checks on the previous head were both pkg/common/compress assertions, not this change:

--- FAIL: TestCompressAppendGzipBytesLevel
--- FAIL: TestCompressWriteGzipLevel
FAIL	github.com/cloudwego/hertz/pkg/common/compress

This PR touches one line in pkg/protocol/http1/resp/header.go, which the compress package does not import; the failures date from the 2026-08-24 run, and main's own Unit Tests have been green since. The behavioural check for the change is that ConnectionUpgrade now matches the client-side counterpart at pkg/protocol/http1/client.go:756, which already compares against bytestr.StrUpgrade.

Not run locally: this host has no Go toolchain, so the evidence is the rebased diff plus the existing test that covers the header path.