Bad request on authed PATCH request.

[Falx]

Impacted package

Which packages do you think might be impacted by the bug ?

• solid-client-authn-browser
• solid-client-authn-node
• solid-client-authn-core
• oidc-client-ext
• Other (please specify): ...

Bug description

I am using the @inrupt/solid-client-authn-browser library to authenticate (successfuly) and do a PATCH request to my webId using the returned fetch. I always get a CORS error, which is the result of a 400 Bad Request without any headers.
If I do the same request with a http client copying the DPoP token and Authorization header though, that request succeeds.

To Reproduce

1. Setup a Community Solid Server by cloning https://github.com/solid/community-server.git and npm start
2. Register for a webId at http://localhost:3000
3. Render a login button that uses the libraries login() function with http://localhost:3000 as oidcIssuer
4. Retrieve the fetch function and do a PATCH request:
   • Mimetype: application/sparql-update
   • Url http://localhost:3000/{podName}/profile/card
   • Body: INSERT DATA { <ex:s> <ex:p> <ex:o> }
5. Run that code in the browser and see the CORS error

Expected result

The PATCH should succeed. (HTTP 205)

Actual result

CORS error in browser because of header-less 400 Bad Request

Environment

$ npx envinfo --system --npmPackages --binaries --npmGlobalPackages --browsers

  System:
    OS: Windows 10 10.0.19042
    CPU: (6) x64 Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz
    Memory: 17.06 GB / 31.93 GB
  Binaries:
    Node: 14.15.3 - C:\Program Files\nodejs\node.EXE
    npm: 6.14.9 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 91.0.4472.101
    Edge: Spartan (44.19041.1023.0), Chromium (91.0.864.48)
    Internet Explorer: 11.0.19041.1
  npmPackages:
    @angular-devkit/build-angular: ~0.1102.10 => 0.1102.14
    @angular/animations: ~11.2.11 => 11.2.14
    @angular/cli: ~11.2.10 => 11.2.14
    @angular/common: ~11.2.11 => 11.2.14
    @angular/compiler: ~11.2.11 => 11.2.14
    @angular/compiler-cli: ~11.2.11 => 11.2.14
    @angular/core: ~11.2.11 => 11.2.14
    @angular/forms: ~11.2.11 => 11.2.14
    @angular/platform-browser: ~11.2.11 => 11.2.14
    @angular/platform-browser-dynamic: ~11.2.11 => 11.2.14
    @angular/router: ~11.2.11 => 11.2.14
    @inrupt/solid-client: ^1.8.1 => 1.8.1
    @inrupt/solid-client-authn-browser: ^1.8.2 => 1.8.2
    @inrupt/vocab-common-rdf: ^0.7.4 => 0.7.4
    @ng-bootstrap/ng-bootstrap: ^9.1.2 => 9.1.2
    @types/jasmine: ~3.6.0 => 3.6.11
    @types/node: ^12.11.1 => 12.20.15
    bootstrap: ^4.6.0 => 4.6.0
    codelyzer: ^6.0.0 => 6.0.2
    crypto-browserify: ^3.12.0 => 3.12.0
    jasmine-core: ~3.6.0 => 3.6.0
    jasmine-spec-reporter: ~5.0.0 => 5.0.2
    karma: ~6.1.0 => 6.1.2
    karma-chrome-launcher: ~3.1.0 => 3.1.0
    karma-coverage: ~2.0.3 => 2.0.3
    karma-jasmine: ~4.0.0 => 4.0.1
    karma-jasmine-html-reporter: ^1.5.0 => 1.6.0
    n3: ^1.10.0 => 1.10.0
    protractor: ~7.0.0 => 7.0.0
    rxjs: ~6.6.0 => 6.6.7
    stream-browserify: ^3.0.0 => 3.0.0
    ts-node: ~8.3.0 => 8.3.0
    tslib: ^2.0.0 => 2.2.0
    tslint: ~6.1.0 => 6.1.3
    typescript: ~4.1.5 => 4.1.5
    zone.js: ~0.11.3 => 0.11.4
  npmGlobalPackages:
    @angular/cli: 11.2.10
    @nestjs/cli: 7.6.0
    @obelisk/auth: 3.4.0
    @obelisk/client: 2.10.2
    npm-check-updates: 10.2.5
    rm: 0.1.8

[Vinnl]

Hi @Falx, unfortunately I'm unable to reproduce this - could you provide some more info? I'm not too familiar with CSS, but after cloning that repo, running npm ci then npm start, if I then visit http://localhost:3000 I just get served a Turtle file, i.e. no way to perform step 2.

That said, I expect this to be an issue in CSS, so I've subscribed to CommunitySolidServer/CommunitySolidServer#777 as well. I think CSS needs to set some response headers to allow for requests with the authentication request headers. Edit: never mind, I see you did include those headers yourself when sending the request manually. If you can help me reproduce it I can look at it further.

Edit 2: although it's interesting that your request body contains undefined prefixes (e.g. <pp:hasPaymentPointer> rather than, say, <http://paymentpointers.org/ns#hasPaymentPointer>) - that might be something to look into?

[Falx]

Edit 2: although it's interesting that your request body contains undefined prefixes (e.g. pp:hasPaymentPointer rather than, say, http://paymentpointers.org/ns#hasPaymentPointer) - that might be something to look into?

I did look into that, I just simplified it to a body that works without the library. I'll try to get a reproducer project going.

[Falx]

If you clone this repo, you should be able to reproduce it. I used a test account on solidcommunity instead of the CSS, since I believe the issue is unrelated to the CSS.

https://github.com/Falx/patch-test

Steps are in the readme.

[Vinnl]

Thanks for the detailed reproduction, and verifying that it also happens against other servers, that really helps.

I think I've identified the problem, and it's somewhat silly: the CORS requests asks the server to allow it to send a PATCH request, but you're sending a patch request - i.e. lowercase vs. uppercase. If I change that line into an uppercase PATCH, the request succeeds for me.

Could you verify whether that resolves your issue?

[Falx]

Really? I tried that before 🤔? Must not have been thorough in testing that. It does seems to work indeed, thanks!

On a side note: The 'PUT' request is also lowercase and does succeed.

[Vinnl]

Yeah, that's a weird inconsistency that you're not the first to trip over.

See:

• PATCH verb whatwg/fetch#50
• Add PATCH to normalized method names JakeChampion/fetch#243
• https://fetch.spec.whatwg.org/#concept-method-normalize

Thanks for reporting back!