You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The server treating Upgrade as implying Connection: close might be a good start, counter to what Section 4 currently says. We should not be recommending mitigations that only one affected party can deploy.
In other words, we would instruct servers to close the connection after responding, without reading any more requests, when they reject an Upgrade.
This behavior would be compatible and compliant, and would foreclose the security issue in question. However, it would have a notable performance cost when returning a response that will trigger a retry (e.g. 307, 401, 407).
The text was updated successfully, but these errors were encountered:
I've added this to #2821 in the context of HTTP CONNECT.
I don't think this mitigation makes sense for Upgrade, because there is no widely deployed vulnerable client that would justify a costly server-side intervention. However, for HTTP CONNECT, it does seem like there may be some clients that are already doing the wrong thing, so a server-side mitigation may be justified.
@martinthomson writes
In other words, we would instruct servers to close the connection after responding, without reading any more requests, when they reject an Upgrade.
This behavior would be compatible and compliant, and would foreclose the security issue in question. However, it would have a notable performance cost when returning a response that will trigger a retry (e.g. 307, 401, 407).
The text was updated successfully, but these errors were encountered: