Uncaught (in promise) Error: Unable to fetch protocol negotiation info: URL returned [201]

[hexagon6]

Search terms you've used

Based on firefox devtools console output

Uncaught (in promise) Error: Unable to fetch protocol negotiation info: <redacted URL> returned [201]

Bug description

When using WebsocketNotification and calling .connect(), negotiation fails.
The server responds with "201 Created", but execution of the client library stops there.

Debugging in Browser shows me the following Request payload for POSTing to e.g. https://solid.mydomain.com/storage/:

{"protocols":["ws"],"features":[]}

Uncaught (in promise) Error: Unable to fetch protocol negotiation info: https://solid.mydomain.com/storage returned [201] 

To Reproduce

1. Use Community Solid Server 7 as your POD software
2. Set up a webid profile
3. Try to subscribe to any SolidDataset location
4. Check server response to be HTTP 201 instead of HTTP 200 (I don't know what the solid spec says should be the right code)

Minimal reproduction

      const resourceUrl = new URL('https://solid.mydomain.com/storage/')
      const websocket = new WebsocketNotification(resourceUrl.href, {
        // fetch is an authenticated instance
        fetch,
      })
      websocket.connect()

Expected result

Do not fail on HTTP Status code 201

Actual result

Fails on HTTP Status code 201

Environment

$ npx envinfo --system --npmPackages --binaries --npmGlobalPackages --browsers
  System:
    ...
  Binaries:
    Node: 20.11.0 - ~/.nvm/versions/node/v20.11.0/bin/node
    npm: 10.2.4 - ~/.nvm/versions/node/v20.11.0/bin/npm
    bun: 1.0.25 - ~/.bun/bin/bun
  npmPackages:
    @hexagon6/svelte-solid-store: ^0.3.2 => 0.3.2 
    @hexagon6/svelte-solid-webid-check: ^0.4.0 => 0.4.0 
    @histoire/plugin-svelte: ^0.17.9 => 0.17.9 
    @inrupt/solid-client: ^1.27.0 => 1.30.2 
    @inrupt/solid-client-authn-browser: ^1.15.0 => 1.17.5 
    @inrupt/solid-client-authn-node: ^1.15.0 => 1.17.5 
    @inrupt/solid-client-notifications: ^2.0.0 => 2.0.0 
    @inrupt/vocab-common-rdf: ^1.0.5 => 1.0.5 
    @inrupt/vocab-solid: ^1.0.4 => 1.0.4 
    @lukeapage/pretty-quick: ^4.0.1 => 4.0.1 
    @playwright/test: ~1.32 => 1.32.3 
    @sveltejs/adapter-auto: ^3.1.1 => 3.1.1 
    @sveltejs/adapter-static: ^3.0.1 => 3.0.1 
    @sveltejs/kit: ^2.5.0 => 2.5.0 
    @types/cookie: ^0.5.1 => 0.5.4 
    ava: ^5.1.0 => 5.3.1 
    buffer: ^6.0.3 => 6.0.3 
    eslint: ^8.27.0 => 8.54.0 
    eslint-config-prettier: ^9.0.0 => 9.0.0 
    eslint-plugin-fp: ^2.3.0 => 2.3.0 
    eslint-plugin-svelte: ^2.32.4 => 2.35.0 
    esm-module-alias: ^2.0.2 => 2.1.0 
    histoire: ^0.17.9 => 0.17.9 
    husky: ^8.0.3 => 8.0.3 
    localforage: ^1.10.0 => 1.10.0 
    node-stdlib-browser: ^1.2.0 => 1.2.0 
    prettier: ^3.0.3 => 3.1.0 
    prettier-plugin-svelte: ^3.0.3 => 3.1.1 
    ramda: ^0.29.0 => 0.29.1 
    svelte: ^4.2.9 => 4.2.9 
    svelte-check: ^3.6.3 => 3.6.3 
    typescript: ^5.3.3 => 5.3.3 
    uuid: ^9.0.0 => 9.0.1 
    vite: ^5.0.0 => 5.0.12 
  npmGlobalPackages:
    corepack: 0.23.0
    npm: 10.2.4

Additional information

[NSeydoux]

Hi @hexagon6 , thanks for reaching out!
I think the core issue here is that the notification protocol implemented by the client library here is pre-specification, so it isn't aligned with the CSS protocol. It is on the roadmap to eventually catch up with the specification, but hasn't been done yet. I'm afraid until this is done, CSS is not supported for notifications.

[hexagon6]

@NSeydoux
How can I help? I've implemented a current-specification for web sockets in my application, which is probably not so trivial to generalize, but I know the steps needed to get it working. Is the roadmap publicly available?

Hi @hexagon6 , thanks for reaching out! I think the core issue here is that the notification protocol implemented by the client library here is pre-specification, so it isn't aligned with the CSS protocol. It is on the roadmap to eventually catch up with the specification, but hasn't been done yet. I'm afraid until this is done, CSS is not supported for notifications.

[hexagon6]

@NSeydoux Also considering that [email protected] uses now StreamingHTTPChannel2023¶ instead of WebSocketChannel2023¶ is this also planned?

[NSeydoux]

Hi @hexagon6 ,

Unfortunately, we don't have a public-facing representation of the roadmap. If you want to fork the repository and add support for the latest notifications API, I'll be happy to provide feedback and to see that it can be merged in main.

Also considering that [email protected] uses now StreamingHTTPChannel2023¶ instead of WebSocketChannel2023¶ is this also planned?

For the time being, the general plan is to bring ESS and the client libraries up-to-speed with the current spec when we start that effort, so the scope will depend on the timing I reckon.