Display containers even if trailing slash is missing from the URL

[michielbdejong]

No description provided.

[thhck]

CSS' issue on this topic, seems that there is no conflict ( neither obligation ) from the spec perspective, and it could be merged upstream
CommunitySolidServer/CommunitySolidServer#1208
CommunitySolidServer/CommunitySolidServer#1208 (comment)

[bourgeoa]

The patch only works when logged-in, else fails with 401 unauthorized
Example below (I removed manually the /) .
But do not fail with https://bourgeoa.solidcommunitypublic/test the / is always added back

[jeff-zucker]

Also note - I tested /public and it redirected me to /public/ correctly BUT it did not add the trailing slash to the browser location bar URI. NSS does add the slash to the URI.

[jeff-zucker]

The patch only works when logged-in, else fails with 401 unauthorized

I found this behavior

         logged-in  /public/  - view container
  not logged-in  /public/  - view container
          logged-in  /public  - view container
     not-logged-in /public - 401

[michielbdejong]

only works when logged-in, else fails with 401 unauthorized

Ah, good catch! I guess in that case our code is not reached. I'll fix that.

the browser location bar URI. NSS does add the slash to the URI.

I'll look into that as well! Maybe that's a subtle difference between a 301 and a 302 or something.

[michielbdejong]

I have to look at CSS architecture and see where we can do the check for public resources.

[michielbdejong]

Testing this with https://michielbdejong.pivot.pondersource.com/README/

[michielbdejong]

As noted in #29 it's probably better to find a different point in the architecture to address this issue, and then fix it once and for all for both publish and non-public resources, and without confusing the DPoP checker and the locking mechanism.

[michielbdejong]

Maybe the best place to do this is actually in mashlib:
When the Outline.expand: Unable to fetch ... error occurs, try an asynchronous fetch of the current URL but with a slash added/removed, and if that succeeds, redirect to it.

[michielbdejong]

After discussion in Solid OS Matrix chat, we decided that the idea of handling it client-side would be less than ideal, so I'll have another stab at it, server-side. There must be a way to catch a 404/401/403 on the server side, just before it's sent in the http response, and then decide whether it needs to be rewritten to a redirect response.

[michielbdejong]

The trouble is that we don't want to send a redirect if the request would still fail after redirection.
For that, we can't use the whole request handling code path, because the DPoP headers would mis-match on the URL.
We also don't want to expose if the URL exists in the absence of authorization.
Maybe pass an option 'ignore DPoP URL mismatch', and then give the client an opportunity to produce the correct DPoP headers after redirection. This might be a small leap of faith but I think it's safe and doesn't open any attack vectors.
It's not that the client would be able to use ANY DPoP headers, only one that is off by a slash.

[michielbdejong]

Digging into this with tubsproject/devlog#8 - I should probably overwrite the HandlerServerConfigurator.

[bourgeoa]

It is also the only place in CSS where a 404 status is set.