Project

General

Profile

Fileupload clientFileName() differs based on OS

Added by Sebastian Fett almost 3 years ago

Hello Forum,

I am running the same code on 2 different OS, one is RHEL 7 and one is a VM of RHEL 7. One client is directly on the RHEL7 while the one using the VM is on Win10. Now if i Upload exactly the same file on my Linux OS the fu->clientFileName().toUTF8(); returns the name of the file while on the Win10 machine I get the file including the complete path, so say the file is named "geometry.igs" fu->clientFileName().toUTF8(); returns "\\server/user/geometry.igs" vs the "geometry.igs" on the RHEL 7. Now I can scan the returned string for the last "/" and delete everything in front of it as filename shouldnt consist of "/" in my case but I doubt this is the intended behaviour.

Regards Sebastian


Replies (3)

RE: Fileupload clientFileName() differs based on OS - Added by Roel Standaert almost 3 years ago

clientFileName() just tells you literally what the client told you the path to the file was in the Content-Disposition header. I suppose we can think about having Wt filter this so it's really only the name of the file.

RE: Fileupload clientFileName() differs based on OS - Added by Roel Standaert almost 3 years ago

According to the documentation of UploadedFile, that is indeed the documented behavior: https://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1Http_1_1UploadedFile.html#a65d825333c4549e48384ecce40b448ce

We did fail to repeat that same detail in the documentation of WFileUpload, though.

RE: Fileupload clientFileName() differs based on OS - Added by Sebastian Fett almost 3 years ago

That was maybe poorly phrased by me, I dont think it is intended behaviour as browser safety should permit the server to know how the path to the file on the client side looked. I just did the filtering manually. I was simply surprised that it was possible to get the path, which is what I originally desired, but found out that it should be impossible. And the VM is running the same version of firefox as the non VM which again should lead to the same result as that part should be only browser related but apparently it isnt.

    (1-3/3)