On 6 Jun 2002, John McNally wrote:
> The fileupload code is applying url decoding to the post data related to
> regular form fields as well as to the headers which include the
> filename. From the limited testing I have done mozilla and netscape do
> not encode this data. I have asked others and they say clients should
> not encode either of these. Form post data will be encoded for type
> application/x-www-form-urlencoded but not for multipart/form-data.
>
> I am going to remove the code that is assuming it is encoded. Is anyone
> aware of clients that might be doing this incorrectly?
The most relevant RFCs seem to be 2616 (section 3.7.2) and 1867 (section 6
has an example). From these, it's clear that URL encoding should not be
applied to the content posted via multipart/form-data, at least not in the
common case. (Each part is a mime part, so it could definite that it's
content-type was application/x-www-form-urlencoded, but common browser
don't).
Here's the sample post data, from 1867 -- not that space is not URL
encoded in the value for field1:
*****
The client might send back the following data:
Content-type: multipart/form-data, boundary=AaB03x
--AaB03x
content-disposition: form-data; name="field1"
Joe Blow
--AaB03x
content-disposition: form-data; name="pics"; filename="file1.txt"
Content-Type: text/plain
... contents of file1.txt ...
--AaB03x--
*****
As a separate issue -- the default encoding should not be used when
reading in filenames from this service. If the default encoding is
something like ISO-8859-1, things will probably be fine; but if it's a
multibyte encoding, it will generally munge the data.
If it's possible to avoid reading the file has characters (using bytes
instead), that's ideal; if that's not possible, it's probably better to
explicitly specify an encoding which will not munge data. ISO-8859
variants will generally satisfy this requirement.
cheers --
Ed
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
