@skriss @AliceProxy does Contour and Emissary have this upgrade enabled by default as well, similar to Istio ?

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 64.17%. Comparing base (8dd60b1) to head (777aebf).
⚠️ Report is 3645 commits behind head on main.

@@            Coverage Diff             @@
##             main     #867      +/-   ##
==========================================
+ Coverage   64.10%   64.17%   +0.07%     
==========================================
  Files          52       52              
  Lines        7170     7179       +9     
==========================================
+ Hits         4596     4607      +11     
+ Misses       2290     2288       -2     
  Partials      284      284              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Or should we use configuration to determine if we use websocket or not?

@Xunzhuo can you share any reason why a user might have web sockets enabled in the app backend but would like to force disable it in the proxy ?
imho this commit enables web socket upgrade proxying based on client-server web socket capability, and enabling it by default is helping the HTTPRoute owner (app developer) set one less thing to get their apps connected to the outside world.

Emissary will not upgrade to websockets unless explicitly configured by the user

Contour's is also opt-in on a per-route basis (for HTTPProxy). It's not currently supported for Gateway API.

thanks @AliceProxy and @skriss for sharing Emissary's and Contour's implementation.
I proposed enabling it by default for now (and changing this behavior in the future in case the upstream Gateway API is explicit about this feature being opt-in) in the community meeting today and did not receive any objection