Socket.io-client: EXTRA HEADER avec Websocket uniquement

https://github.com/socketio/engine.io-client/blob/27fa6949f38896e18a6ef426516359f8d54e7db6/lib/socket.js#L124

https://github.com/socketio/engine.io-client/blob/master/lib/transports/websocket.js#L63

En lisant le code source mentionné ci-dessus, vous pouvez faire ce travail en:

socketIO('https://example.org', {
  path: '/api/endpoint',
  transports: ['websocket'],
  transportOptions: {
    websocket: {
      extraHeaders: {
        Cookie: 'It works',
      },
    },
  },
});

Et même ça:

socketIO('https://example.org', {
  path: '/api/endpoint',
  transports: ['websocket'],
  extraHeaders: {
    Cookie: 'It works',
  },
});

Sur la base des extraits de code source, il semble en effet qu'il n'y a pas de restriction, mais l'avez-vous testé? Je vais le tester plus tard quand j'aurai le temps, mais si cela fonctionne, la documentation doit être mise à jour, car:

https://socket.io/docs/client-api/#With -extraHeaders:

Avec extraHeaders
Cela ne fonctionne que si le transport d'interrogation est activé (ce qui est la valeur par défaut). Les en-têtes personnalisés ne seront pas ajoutés lors de l'utilisation de websocket comme transport. Cela se produit car la négociation WebSocket n'honore pas les en-têtes personnalisés. (Pour le contexte, voir le protocole WebSocket RFC)

const socket = io({ transportOptions: { polling: { extraHeaders: { 'x-clientid': 'abc' } } }});

Il dit le contraire ...

Salut les gars.
Cela n'a pas fonctionné.
Je viens de le tester dans mes tests d'intégration, cela n'a pas fonctionné.

@najibghadri @behruzz Cela fonctionne pour moi avec l'exemple ci-dessus, et ne mettez pas extreHeader sous sondage

Cela fonctionne pour moi lors de l'exécution dans nodejs, ce n'est pas le cas lors de l'exécution dans Chrome. Cela ne peut pas être fait car il n'est pas pris en charge par l'API du navigateur https://developer.mozilla.org/en-US/docs/Web/API/WebSocket
J'ai besoin de l'en-tête pour que mon équilibreur de charge envoie correctement la demande au serveur socket, mais je pense que nous aurons besoin d'un mécanisme différent

Il semble que quelqu'un pense que cela devrait fonctionner, car également selon la documentation:

extraHeaders | {} | En-têtes qui seront passés pour chaque requête au serveur (via xhr-polling et via websockets). Ces valeurs peuvent ensuite être utilisées lors de l'établissement de liaison ou pour des proxys spéciaux.

Au fait, si vous ne pouvez pas utiliser de cookies, cela signifie-t-il essentiellement que vous ne pouvez utiliser que des adresses IP pour l'équilibrage permanent?

@AvailCat veuillez noter que les exemples que vous avez fournis ne fonctionneront pas dans le navigateur

@rotvr si vous n'utilisez que le transport WebSocket, vous n'avez pas besoin de session

Si vous utilisez le transport d'interrogation, la première requête HTTP définit un cookie ( io ), qui peut être utilisé pour sticky-session.

Plus d'informations ici: https://socket.io/docs/using-multiple-nodes/

Voir aussi: https://github.com/socketio/engine.io-client/issues/635#issuecomment -638713082