views:

53

answers:

1

Hello According to RFC, in multipart/form-data content-disposition header filename field receives as parameter HTTP quoted string - string between quites where character '\' can escape any other ascii character.

Problem web browsers don't do it.

IE6 sends:

Content-Disposition: form-data; name="file"; filename="z:\tmp\test.txt"

Instead of expected

Content-Disposition: form-data; name="file"; filename="z:\\tmp\\test.txt"

Which should be parsed as z:tmptest.txt according to rules instead of z:\tmp\test.txt.

Firefox, Konqueror and Chrome don't escape " characters for example:

Content-Disposition: form-data; name="file"; filename=""test".txt"

Instead of expected

Content-Disposition: form-data; name="file"; filename="\"test\".txt"

So... how would you suggest to deal with this issue?

Anybody?

A: 

Is there a reason that you need to parse this filename at all?

At least the one thing that's consistent is that the filename portion of the header ends with a double quote, so you just need to read in everything between filename=" and the final ".

Then you can probably treat any backslash other than \\, \" or \" as a literal backslash, unless you think it's particularly likely that users will be uploading filenames with tabs in them. :)

Christopher
"Is there a reason that you need to parse this filename at all?" -- yes I want to know the file name ;). "At least the one thing that's consistent is that the filename portion of the header ends with a double quote," The filename and name fields should not come in this specific order, so it is bad idea to suppose that file-name ends with last quotation mark.
Artyom
Want != need. ;) Ok, so you're at least guaranteed that it'll end with `"` or with `"; ` -- with this lack of consistency you have to make some concessions, like relying on the fact that users won't put `"; ` in the middle of their file names :)Alternatively, are you using a web framework that supports a best-effort parsing of this attribute for you?
Christopher