POST does not work the way it did in 4.x

[jeff-zucker]

From my testing (test attached below) I notice these differences:

POST "foo", no content-type                                                     
  4.x : "foo" text/turtle                                                       
  5.x : 500                                                                     
POST "foo.ttl", no content-type                                                 
  4.x : "foo.ttl" text/turtle                                                   
  5.x : 500                                                                     
POST "foo", content-type=text/turtle                                            
  4.x : "foo"     text/turtle                                                   
  5.x : "foo.ttl" text/turtle                                                   
POST "foo.ttl", content-type=text/turtle                                        
  4.x : "foo.ttl.ttl" text/turtle                                               
  5.x : "foo.ttl.ttl" text/turtle                                               

Here's the test. I ran it against solid.community for 5.x and against solid.openlinksw.com:8444 for 4.x

const auth       = require('solid-auth-cli')
const text       = "<> a <#test>."

const idp  = "https://jeffz.solid.community"
const base = idp + "/public/nss5-test/"
const file = "test-file"

async function main(){
  let session = await auth.login()
  console.log("Logged in as <"+session.webId+">")
  console.log("Using folder <"+base+">\n")
  await test({
     label       : "POST, no content-type",
     extension   : "",
     contentType : ""
  })
  await test({
     label       : "POST content-type=text/turtle",
     extension   : "",
     contentType : "text/turtle"
  })
  await test({
     label       : "POST, no content-type",
     extension   : ".ttl",
     contentType : ""
  })

}
async function test(opts){
  let url = file + opts.extension
  console.log("    ",opts.label,"<"+url+">")
  let headers = {
    link : '<http://www.w3.org/ns/ldp#Resource>; rel="type"',
    slug : url,
  }
  if(opts.contentType) headers["Content-type"]=opts.contentType
  let res = await auth.fetch( base, {
    method:"POST",
    body:text,
    headers:headers
  })
  if(!res.ok){
    console.log("        ",res.status,res.statusText)
    return
  }
 let location = idp + res.headers.get("location")
 res = await auth.fetch( location )
 location = location.replace(base,'')
 if(res.ok) console.log(
      "        ",
    res.status,
    res.headers.get("content-type"),
    location
  )
  else console.log("        ",res.status,res.statusText)
}
main()

[Otto-AA]

Edit: I've misread the OP, following is slightly off topic...

I've already mentioned this behaviour in this issue, that the slug and the mapped content-type just get joined together. So having slug: file.xyz and Content-Type: text/turtle will result in file.xyz.ttl

Here is the part of the code which I think causes this (in particular line 440):
https://github.com/solid/node-solid-server/blob/5adcd47238778366128fc6ec3dd51186ca86c3b4/lib/ldp.js#L435-L446

[jeff-zucker]

@Otto-AA's point is a good one and I support following up on that. Ironically, that's the only one of the four I posted that matches 4.x behavior. Tim has said #1165 (comment) that PUT without content-type is not valid and I'm wondering if this also applies to POST, in which case the 500 in the first two cases is correct though not-backward compatible. The third case above is concerning to me because it means it is impossible to create a Turtle resource that has no extension - if it isn't valid to create without sending a content-type and sending a content-type always tacks on an extension that means all resources have extensions. Perhaps this is by design, but it bears some thought.

[Otto-AA]

Regarding the 500 response if no Content-Type is provided, I want to add that I would expect a 400 response in such a case. Apart from that I completely agree with @jeff-zucker that clarification on this issue would be helpful.

[jeff-zucker]

Yes, 400 is more accurate than 500.

[jeff-zucker]

Another serious problem reported by a user : how does one create foo.acl? It fails with no content-type and creates foo.acl.ttl with content-type "text/turtle".

[jeff-zucker]

To summarize what I'd like to see:

• PUT or POST with no content-type specified

     * either 400 or 415 
     * or if you feel forgiving, default to text/turtle :-)

• PUT or POST with content-type specified

    * create with that content-type
    * server does not ever append an extension

All assuming the user has write permissions.

[RubenVerborgh]

Another serious problem reported by a user : how does one create foo.acl? It fails with no content-type and creates foo.acl.ttl with content-type "text/turtle".

PUT or POST?

It should be done with PUT, but I can very well imagine that failing currently if the .acl extension is not treated as a special case.

[jeff-zucker]

@RubenVerborgh Yes, PUT can create resources with no extensions and with a .acl extension. But why should NSS add extensions with a POST? What is the point of demanding that with content-type specified as text/turtle foo becomes foo.ttl and foo.ttl becomes foo.ttl.ttl and foo.acl becomes foo.acl.ttl? None of those make sense to me but maybe I'm missing something.

[RubenVerborgh]

But why should NSS add extensions with a POST?

It shouldn't; but POST shouldn't be used to create ACL resources, as the resource URL is unpredictable (and needs to be predictable for ACL).

[jeff-zucker]

Hmm, thanks, that is a great explanation of why PUT is needed in that case. It hadn't occurred to me.