Gracefully handle redirect for DPoP

[NSeydoux]

Since a DPoP header is scoped to one target IRI, if the request is redirected, the DPoP header is invalid, which results in a 401 unauthenticated. To fix the issue, the fetch must capture the redirection, and replay the request to the actual target IRI.

This is particularly useful when requests target a container, but omit to include the trailing /.

Fixes #89.

Checklist

• All acceptance criteria are met.
• The changelog has been updated, if applicable.
• Commits in this PR are minimal and have descriptive commit messages.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 4080b26:

Sandbox	Source
solid-client-auth-browser-demo	Configuration

[NSeydoux]

Note that unlike it was initially planned for, this does not throw on redirect: the DPoP token is rebuilt, and the request re-sent to the target IRI.

[Vinnl]

I'm not quite following how this works yet, so I left a question inline.

Also, it seems like this might be a good candidate to add and end-to-end test for? Since it's so particular to server behaviour.

[NSeydoux]

Good point, an end-to-end test would be a nice addition to this feature. i'll add one to the current PR.

[pmcb55]

This does look a bit shaky, but I'll approve to get PB moving (I assume test coverage is good...!?)

[NSeydoux]

Coverage is 100% for the code impacted by this PR, and an e2e test is also added to verify that fetching https://my.pod/private ends up fetching https://my.pod/private/ successfully. The bits added in the fetch basically aim at not re-issuing any unnecessary request, meaning the initial request hadn't been redirected and had an auth issue, or it had a non-auth issue. 401 and 403 are the only errors that I can see making sense in this context: a request rejected because the provided credentials aren't accepted by the server because of the redirection. Actually typing this, it seems that only 403 makes sense: you are authenticated, but the credentials aren't accepted. If you aren't providing any authentication, retrying the request won't help.

[NSeydoux]

Ah yeah right, after a quick test I verified that NSS does return 401 for an authenticated request that gets rejected for DPoP mismatch reasons. I'll log a bug ticket in NSS, and add a link in the code.

Well actually https://developer.mozilla.org/en-US/docs/Web/HTTP/Status and https://tools.ietf.org/html/rfc7235#section-3.1 contradict each other on this: the former specifically says that 401 means credentials are lacking, while the latter says it also applies when credentials are present but not accepted by the server, so I guess technically NSS's response makes sense as well.