Handling duplicate file names

Hi all!

A question regarding the NSS: how does it resolve duplicate file names before the extension?

For example, say I make a request for “user.somedomain.com/profile/a_file”. Once that request hits the NSS it attempts to resolve the url in the ResourceMapper.js class which attempts to match the directory path “/profile/a_file” and the data store “user” to a file.

Whilst matching it runs

match = files.find(f => this._removeDollarExtension(f) === filename)

(line 123 in ResourceMapper.js).

where _removeDollarExtension() is:

 // Removes dollar extensions from files (index$.html becomes index)
  _removeDollarExtension (path) {
    return path.replace(/\$\.[^$]*$/, '')
  }

So the question is: what if there are two files named “a_file”?

  • File1: profile/a_file$.someExtension
  • File2: profile/a_file$.differentExtension

How does it resolve the request? Or is there some part of the code that prevents identical filenames before the extension in the same directory?

Hi,

I’ve been exploring the ResourceMapper as well but have much to learn:
image

posted primary-disk.scad first and that was there
then primary-disk.txt
folder view had
primary-disk.scad$txt
primary-disk.txt

then I added a third file primary-disk.bac and got
primary-disk.bac$txt
primary-disk.scad$txt
primary-disk.txt

it seems the $ is postfixed after the extensions where the file without the $ has extension matching all the others after the $

1 Like

Good Stuff!

So what happens when you try and a retrieve one of these files via the browser without the extension type? e.g: “https://user.solid.com/path/to/primary-disc”.

I’m still attempting to debug “internal server error 500” on every instance i install locally, so can’t actually upload anything to test this!

In firefox get:

image

I’m using a clone of the repository master HEAD on Jul 13 22:16

On the 500 error - make sure you are sending a content-type. Version 4.x of NSS accepted a PUT or POST with no content-type specified and/or tried to guess the content-type from the extension. In version 5.x NSS currently gives a 500 error for attempts to create a resource without a content-type. This will eventually be changed to be a 400 or 415 error because it is actually invalid to try to create a resource without a specified content-type so get used to including them. In the current state of things, using PUT to create resources avoids many of the extension naming problems although in the long-run, turtle resources should use POST.

1 Like

I’ll check that out when i have the time - i’m working on my MSc thesis at the moment so a little short on it!

I haven’t tried manually creating the requests and was simply using the provided Data Browser: all PUT/POST requests returned Error 500, and some GET requests.

Thanks for the tip

This strikes me as the expected behaviour based on the code in ResourceMapper. Though it also seems problematic and prone to attacks/inadvertent gaffes:

  1. HEAD request to see what resources exist,
  2. PUT/POST to create a resource with the same name,
  3. Server is now unable to return the original resource due to duplicate pre-extension naming

… perhapse the server should throw a “Content Negotiation” related error?

This would be apt as the problem seems to be that two resources can actually live at the same URI based on the way the NSS resolves requests.

I’m just fleshing out the problem here, but i suppose it would only occur if neither of the resources has a “ttl” file type (as requests to a solid server shoudl default to Content-Type: text/turtle as per the spec.