prevent absolute file path in Content-Disposition “filename”

Question

I have a simple HTML Form

<form id="uploadForm" method="post" action="/cgi-bin/test.cgi" enctype="multipart/form-data">
   <input type="submit" name="add_something" value="add">
   <input size="50" type="file" name="myFile" accept="application/zip">
</form>

In addition I do some web page localization on server side by checking user browser locale or searching for a self set language session cookie.

If I upload a file with

• Iron 18.0.1050.0
• Opera 11.64.1403
• Firefox 3.6.27
• Firefox 12.0
• Google Chrome 19.0.1084.52
• SeaMonkey 2.9.1

all works fine. But If I upload a file with

• IE 9.0.8112.16421
• Maxton 3.3.8.3000

the localization fails. I detected the issue inside the HTTP request:

Opera 11

Content-Disposition: form-data; name="myFile"; filename="ziptest.zip"
Content-Type: application/zip

and IE 9

Content-Disposition: form-data; name="myFile"; filename="C:\Documents and Settings\m1krsch\Documents\Now Some Spaces\ziptest.zip"
Content-Type: application/x-zip-compressed

If I remove the spaces from the path all works fine in IE and Maxton.

Neighter can I exchange the used cgicc library because it is fixed part of the project nor can I force a user to use a path without spaces. How can I circumvent this issue? Is there a way to force IE/Maxton to use the filename instead of the abolute filepath? Or can I set a specific parameter in cgi/env to prevent transmission of abolute filepath?

[EDIT] I found out that this is a security issue in IE and Maxton. The security zone model of IE allows by default to "Include local directory path when uploading files". I can disallow this behaviour only by changing the client configuration but I am still searching for an application-based solution. [/EDIT]

Answer 1

I found a stupid error in my localization code. I am using RapidXML for this and encapsulate the whole localization code and RapidXML headers in one class. Unfortunately I did not read the documentation very careful. The data inside vector<char> object - which is holding the XML document data - is not copied into the XML document object xml_document<> by using the parse() method as expected. This looks like procedural C code to me and is in my opinion bad OOD. The documentation says:

3.1 Lifetime Of Source Text

In-situ parsing requires that source text lives at least as long as the document object.

The problem vanished when I corrected my code to get a global vector<char> object inside my localization class.

Nevertheless I am perplexed why mostly all other browsers have no problem with my old code.

Answer 2

Try replacing the spaces with '%20':

"C:\Documents%20and%20Settings\m1krsch\Documents\Now%20Some%20Spaces\ziptest.zip"