Yes, you’re right, it isn’t entirely cosmetic though it doesn’t prevent copying. From what I can see, it only applies to index.html in the pod root. I haven’t seen it with any other file in the pod root or with index.html in other containers.
Yes, wierd. I am going to investigate myself. Perhaps we can fix it together
2 Likes
Thats awesome thanks for this @jeffz.
I tried to use the demo but i am getting following error when i tried to upload file or copy.
SFCFetchError 403
https://mano.solid.community/public/Version.docx - Make sure that the user has access to the resource
A 403 is an unauthorized origin error. Have you given your app trustedApp status in your profile? I’m changing the error message for 403 to “Make sure that the origin of your app is authorized for your pod”
If you are using the online demo, you’ll need to authorize the origin https://jeff-zucker.github.io (no trailing slash)
Yes! that trailing slash made this error. It works now. Thanks! I am trying to implement a upload function preconfigured with credentials. But getting no session error.
let credentials = {
“idp” : “https://solid.community”,
“username” : “Manotest2”,
“password” : “password”, // OPTIONAL !!!
“base” : “https://manotest2.solid.community”,
“test” : “/public/fitness/”
};
const auth = require(‘solid-auth-cli’);
const FC = require(‘solid-file-client’);
const fc = new FC( auth );
let podfolder = “https://manotest2.solid.community/public/fitness/file”;
let local = “/data/web/blck/node/solidblcn/solidbcn/temp/file”;console.log(“Initialising solid login”);
let session = await auth.currentSession()
if (!session) { session = await auth.login(credentials) }
console.log(Logged in as ${session.webId}.)
try {
await auth.login()
console.log(“actually trying to copy now”);
await fc.copyFile( local, podfolder )
}
catch(err) {
console.log(err)
}
@Leoudayan which version of solid-auth-cli and solid-file-client have you installed? Ensure to use the latest ones.
1 Like
Looks like you login twice the second time without credentials
@aveltens i am uing 2.4.1 latest version of solid auth client and 1.0.1 version of solid file client.
@jeffz even after removing the auth.login part, i am getting the same error. Following is the full log.
(node:879) UnhandledPromiseRejectionWarning: Error: No session!
at Object.currentSession (/data/web/blc/node_modules/solid-auth-cli/src/index.js:58:18)
at Object.exports.upload (/data/web/blc/node/solidblcn/solidbcn/models/exp1.js:77:28)
at exports.upload (/data/web/blc/node/solidblcn/solidbcn/controllers/exp1controller.js:15:16)
at Layer.handle [as handle_request] (/data/web/blc/node/solidblcn/solidbcn/node_modules/express/lib/router/layer.js:95:5)
at next (/data/web/blc/node/solidblcn/solidbcn/node_modules/express/lib/router/route.js:137:13)
at Route.dispatch (/data/web/blc/node/solidblcn/solidbcn/node_modules/express/lib/router/route.js:112:3)
at Layer.handle [as handle_request] (/data/web/blc/node/solidblcn/solidbcn/node_modules/express/lib/router/layer.js:95:5)
at /data/web/blc/node/solidblcn/solidbcn/node_modules/express/lib/router/index.js:281:22
at Function.process_params (/data/web/blc/node/solidblcn/solidbcn/node_modules/express/lib/router/index.js:335:12)
at next (/data/web/blc/node/solidblcn/solidbcn/node_modules/express/lib/router/index.js:275:10)
(node:879) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:879) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
One odd thing i am noticing is that i am getting the following warning near the solid-auth-cli and solid-file-client declaration
Could not find a declaration file for module ‘solid-auth-cli’. ‘/Volumes/blockchain20.kmi.open.ac.uk/node_modules/solid-auth-cli/src/index.js’ implicitly has an ‘any’ type.
Trynpm install @types/solid-auth-cliif it exists or add a new declaration (.d.ts) file containing `declare module ‘solid-auth-cli’;
Sorry, I meant solid-auth-cli
Ah yes!!! i didnt realise that solid-auth-cli and solid-auth-client are different. It worked now!! Once again thanks a lot @jeffz for creating this and thanks both for helping me to fix the issue @aveltens.
2 Likes
@aveltens - @bourgeoa found the issue with your index.html error - an NSS bug. Apparently NSS doesn’t send a content-type for index.html in the pod root and Solid-File-Client was erroring when it tried to read its headers for purposes of copying linked files. We’ll trap the error on our end better though, it shouldn’t interfere with copying.
Ah, thats great Jeff! Did you file a NSS bug already? Thanks a lot for all your efforts
Hi @jeff, I cannot reproduce this.
curl https://pod-homepage.solid.community/ -I
curl https://pod-homepage.solid.community/index.html -I
both return Content-Type: text/html; charset=UTF-8
What lead you to the assumption?
The fun(?) thing is: https://pod-homepage.solid.community/index.html actually does not return the actual index.html file I stored at the Pod root, but the “Solid Data Browser” page 
I mis-wrote, it returns a content-type, but not a link header. For example, this returns null:
const auth = require('solid-auth-cli')
const podIndex = "https://jeffz.solid.community/index.html"
auth.login().then(
auth.fetch( podIndex ).then( response =>
console.log( response.headers.get("link") )
)
)
Ah yes, I see. I think this is acutallly related to the fact, that an explicit request of index.html returns the Data browser page and not the actual resource.
I found an issue regarding that behaviour Requesting index.html from root will serve the data browser, not the file itself · Issue #1345 · nodeSolidServer/node-solid-server · GitHub
1 Like
The pod root index.html is an edge case from about three different angles. But we’re fixing Solid-File-Client so that the error you reported is only triggered if you are also trying to copy linked resources.
1 Like
Cool 
but copying linked resources is the default, isn’t it? Should it not work even without a Link header? The resource just doesn’t have linked resources in that case?
LOL. Take a look at the lengthy conversation on this issue that Alain, Otto, and I have been having about this exact question. In the end we decided to only error in the case where there is an index.html.acl in the source but no .acl link in the target’s header and the user use the default withAcl=true.
1 Like
That sounds reasonable. 
Implemented in 1.0.2, now on npm. It should no longer show an error in your situation. Thanks for your ongoing help.