Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Server sends phantom WebSocket pub messages

Offen
#1,587 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
javascript
Bereich
api, backend

Rechercherichtung

Beginnen Sie mit dem gemeldeten POST an den Posteingang des Empfängers und verfolgen Sie die Verarbeitung der WebSocket-Veröffentlichung des Servers für die daraus resultierenden pub-Nachrichten. Vergleichen Sie den Zustand und die Request-Pfade des Posteingangs des Senders und des Empfängers und überprüfen Sie anschließend, dass Benachrichtigungen nur für die Ressource ausgegeben werden, deren CRUD-Operation geändert wurde.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Based on the spec (https://github.com/solid/solid-spec/blob/master/api-websockets.md#subscription), client can subscribe and the server will send WebSocket pub messages on CRUD operations. I use this for inbox monitoring - notify user about new messages in his Solid inbox. So when anybody POSTs to his inbox, solid server sends WS pub message to my application, this works fine.

However, there are "phantom" WS pub messages even when there is no user-triggered CRUD operation on the inbox. From the spec, it should be only when POST, PUT, PATCH or, DELETE happens on the source.

Now, this is hard to debug/investigate. But I can reproduce it, using my application https://whyineedtofillusername.github.io/inbox/:

  1. login using WebID
  2. send a message to any other WebID (lastly I tried sending messages between https://inbox1.inrupt.net/profile/card#me and https://inbox4.inrupt.net/profile/card#me, using Activity Streams message functionality; one in Chrome and the other user in Firefox)
  • the only request the application does is this POST request (copied from Chrome, user Inbox1 sending message to user Inbox4):
POST /inbox/ HTTP/1.1
Host: inbox4.inrupt.net
Connection: keep-alive
Content-Length: 437
sec-ch-ua: "Google Chrome";v="89", "Chromium";v="89", ";Not A Brand";v="99"
Accept: application/json, text/plain, */*
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36
Content-Type: application/ld+json
Origin: https://whyineedtofillusername.github.io
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://whyineedtofillusername.github.io/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9

{..} (json payload)

The request above produces WS message

pub https://inbox1.inrupt.net/inbox/

image

Now there shouldn't be any reason for this, but it looks like the solid server is doing some CRUD operation on the sender's inbox as well. Is this intentional? When I compare the RDF for https://inbox1.inrupt.net/inbox/ before and after sending the message, there is no change (not even the "terms:modified" has changed). So it doesn't look like there's been any CRUD operation on the source.

Vorherrschende Sprache
JavaScript
Sterne
1.8k
Forks
308
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus nodeSolidServer/node-solid-server

Alle Issues in nodeSolidServer/node-solid-server

Ähnliche Issues

Weitere Issues zu JavaScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.