Fail on no content-type?

[jeff-zucker]

The spec requires a content-type for PUT and POST. Solid-Rest currently fails if it is missing. This causes 4 tests on Solid-File-Client to fail. I suggest that we make failure of PUT and POST without content-type an error in Solid-File-Client. If, instead, we want to guess the content-type from the extension, we should trap the error in Solid-File-Client rather than making rest go against the spec. @bourgeoa - thoughts?

[bourgeoa]

First thoughts :

• I have to look at the results with more details.
• I rerun the tests on https and file :
  -- v1.2.2 : all tests except one passes (1) on NSS v5.6.4 for test:https, and test:file
  -- v2.0.6 : all tests except one passes (1) on NSS v5.6.4 for test:https, and 29 tests fails on test:file

I think that most problems comes from solid-rest.

(1) core methods > getters >head resolves with Content-Tyep text/turtle for folder
expected : text/turtle
received : application/octet-stream

To have more information on tests you can add --verbose : npm run test:file --verbose

[jeff-zucker]

With 2.0.6, 29 tests fail on https? So none of those are solid-rest issues?

[bourgeoa]

No all are solid-rest issues.

• There is only one error on https. see above.
• 29 errors for test:file

[jeff-zucker]

Ah, ok. What does NSS do when it gets a PUT or POST without a content-type?

[bourgeoa]

The spec requires a content-type for PUT and POST. Solid-Rest currently fails if it is missing. This causes 4 tests on Solid-File-Client to fail. I suggest that we make failure of PUT and POST without content-type an error in Solid-File-Client. If, instead, we want to guess the content-type from the extension, we should trap the error in Solid-File-Client rather than making rest go against the spec.

no reason to go against spec. PUT and POST MUST have contentType
We have to go deeper to each case :
for example PATCH has no contentType but ends with PUT with a contentType

I shall try to look in more detail to solid-rest

[jeff-zucker]

Solid-Rest fails for any PUT or POST without a content-type, but that causes 4 of the 29 test-failures. When I don't fail on missing content-type, 25 tests pass.

[bourgeoa]

Ah, ok. What does NSS do when it gets a PUT or POST without a content-type?

error 400
https://github.com/solid/node-solid-server/blob/e8aad197d307b42cdac6985c76a1fe6ee9c71f52/lib/ldp.js#L240

[jeff-zucker]

Hmm deleteFolder() returns an array so one can't say let response = await deleteFolder(url); console.log(response.status). Is that what you'd expect?

[jeff-zucker]

I am unable to cause an error running createFolder() on public or private resources on solidcommunity.net with or without a pre-existing folder of the same name.

const SolidFileClient = require('./');

const {SolidNodeClient} = require('solid-node-client');
let auth = new SolidNodeClient();
let fc = new SolidFileClient(auth);
const creds = require('./creds');
let folder = "https://jeff-zucker.solidcommunity.net/private/test-folder/";
let r; // response

async function main(){

  // login
  let session = await auth.login(creds);
  if(!session.isLoggedIn){ console.log("Could not login!"); process.exit(); }
  else console.log(`logged in as <${session.WebID}>`);

  // if prexists, deleteFolder
  if( await fc.itemExists(folder) ){
    r = await fc.deleteFolder(folder);
    console.log( "Deleting Folder : ",r.status );
  }

  // createFolder
  if( await fc.itemExists(folder) ) console.log( "Folder Exists." )
  else console.log("Folder does not exist.");
  r =  await fc.createFolder(folder);
  console.log( "Creating Folder : ",r.status )

  // createFolder again
  if( await fc.itemExists(folder) ) console.log( "Folder Exists." )
  else console.log("Folder does not exist.");
  r =  await fc.createFolder(folder);
  console.log( "Creating Folder : ",r.status )

  // deleteFolder
  r = await fc.deleteFolder(folder);
  console.log( "Deleting Folder : ",r[0].status );
}
main();

[jeff-zucker]

^^^ using 2.0.6

[jeff-zucker]

Also tried when creating with intermediate non-existant folders, still no error.