Websocket: [Frage] Warum werden 'Sec-WebSocket-Extensions'-Header vom Upgrader nicht unterstützt.

Wie im OP erwähnt, habe ich dies vom ursprünglichen Problem verschoben, um dieses Problem beizubehalten. Um die Frage selbst zu beantworten; Ich glaube (nach einiger Lektüre), dass dies wirklich nur mit der enthaltenen (experimentellen) Implementierung von RFC7692 zusammenhängt.

Schauen Sie dazu auf https://godoc.org/github.com/gorilla/websocket#hdr -Compression_EXPERIMENTAL
Sie sollten dort die Komprimierung per Boolean aktivieren können, anstatt den Header selbst anzuhängen.

@elithrar Dieses Problem wurde behoben und kann geschlossen werden.

@nhooyr darf ich wissen, in welcher Version gelöst wurde?
Ich verwende v1.4.2 und wenn ich das r.Header erhalte ich den gleichen Fehler wie bei @IngCr3at1on erwähnt

conn, err := upgrader.Upgrade(w, r, r.Header)

websocket: application specific 'Sec-WebSocket-Extensions' headers are unsupported

websocket: anwendungsspezifische 'Sec-WebSocket-Extensions'-Header werden nicht unterstützt

Dieser Header- Fehler bedeutet also, dass Sie Sec-WebSocket-Extensions festlegen, bevor Sie Upgrade aufrufen. Sie müssen nur damit aufhören, da Sie keine benutzerdefinierte Erweiterung verwenden können (eine, die keine RFC 7692- Komprimierung ist).

Du musst nur damit aufhören

Hör auf, r.Header im Upgrade() zu übergeben, meinst du?

danke für den Referenzlink. ich kann sehen

1. Verlängerungsverhandlung
   Um die Nutzung eines PMCE anzubieten, MUSS ein Client den Erweiterungsnamen von
   das PMCE im Header-Feld "Sec-WebSocket-Extensions" seines
   Handshake der WebSocket-Verbindung öffnen.

Also nicht sicher, wann du sagtest

Sie können keine benutzerdefinierte Erweiterung verwenden

Das bekomme ich als Antwort und die Anfrage im Browser. wenn ich r.Header an Upgrade() .

Übrigens, ich verwende das Gorilla-Chat-Beispiel genau für die Client-Seite und keine Änderungen am js-Code. Auf der anderen Seite sende ich auf dem Server keinen benutzerdefinierten oder manuellen Header als Antwort auf die Anfrage des Clients.

Um diesen Fehler zu vermeiden, um nur das Ergebnis zu erhalten, kann ich den Ursprung manuell validieren, was ich nicht tue. Dies ist die Produktionsebene / richtige Lösung!

var Upgrader = websocket.Upgrader{
    ReadBufferSize:  1024,
    WriteBufferSize: 1024,

    CheckOrigin: func(r *http.Request) bool {
        if r.Header.Get("Origin") == "http://localhost:9090" {  // <=====
            return true
        }
        return false
    },
}                                                             

Darf ich fragen was die richtige/Produktionsstufe ist?

Außerdem kann ich im Beispiel sehen, dass sie nil als responseHeader . Wenn wir also nil übergeben müssen, warum hat die Funktion den responseHeader-Parameter ?

func (u *Upgrader) Upgrade(w http.ResponseWriter, r *http.Request, responseHeader http.Header) (*Conn, error)

Ich denke, Sie sind verwirrt, wofür responseHeader gedacht ist. Sehen Sie sich die Dokumentation zu Upgrade und überprüfen Sie den Quellcode.