You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by maciek <ma...@pb-network.com> on 2003/06/28 19:46:31 UTC
[PATH]FileUpload fix for filename for msiexplorer
Method getName() in DefaultFileItem.java class when used with
msiexplorer 5/6 returns a filename with the whole client's filesystem
path which creates a problem when you want to save the file on a
server's filesystem. I have chanaged the implementation of the getName()
method to strip the path information from the filename.Below is my
proposed implementation for getName() method:
public String getName()
{
if(fileName.lastIndexOf("\\") != -1){
return fileName.substring(fileName.lastIndexOf("\\") + 1);
}else{
return fileName;
}
}
I have attached the fileName_fix_forMSIE.txt patch file.
I have rebuild the entire source code to create a new jar and tested it
with Tomcat and Resin. It works now with MSIE. A simple call to
item.getName() returns only filename where item is of type FileItem.
I think that it would be a better idea to change the implementation of
the method without breaking of the FileUpload component interface than
letting web developers to take care of the problem inside a jsp file.
I think users of the component should use the method transparently
without worrying about the possible problem with MSIE with the guarantee
that ONLY filename will be returned from getName() method.
Regards,
Maciej Brodala
RE: [PATH]FileUpload fix for filename for msiexplorer
Posted by maciek <ma...@pb-network.com>.
My problem came out when I was working on an administration module with
the ability to upload files to client's directory on a linux server, to
be more specific mostly images to be displayed on a client's web site.
FileUpload component when used with netscape uploaded only the file
which was what I wanted, but with MSIE the whole path was saved as, for
example : /home/clientA/C:\Documents\myImages\test.jpg and was not
usable. Then I tested for user-agent in a jsp file and parse a return
String from getName() accordingly stripping the path info if it was MSIE
client.This quick/simplistic and not robust solution worked for my
administration module requirements and
I do understand that there may not be the need to implement this
functionality in the component like Martin Cooper explained making a
strong point for it and leave it to web developers and their
applications requirements.
Regards,
maciej
ps.I would like to thank everybody for valuable insights so far to help
me look at the issue from different points of view.
On Sat, 2003-06-28 at 16:05, Noel J. Bergman wrote:
> > FileUpload should not be in the business of deciding, on behalf of its
> > client, how to interpret the content of fields uploaded by the browser.
>
> +1
>
> > > Method getName() in DefaultFileItem.java class when used with
> > > msiexplorer 5/6 returns a filename with the whole client's
> > > filesystem path which creates a problem when you want to save
> > > the file on a server's filesystem.
>
> What if I were storing information in a database, and wanted to preserve the
> client's fields, or had some other need for the path?
>
> What guarantee is there that the filename, even without the path, is valid
> for the server? What if the client OS uses a different set of allowable
> symbols? What if I already have a file of that name from another user?
> What if ... ? Simply stripping the path from the name isn't going to
> address the problem.
>
> Besides which, this functionality is already in java.io.File:
>
> import java.io.File;
> public class filename {
> public static void main(String[] args) {
> System.out.println(new File(args[0]).getPath());
> System.out.println(new File(args[0]).getParent());
> System.out.println(new File(args[0]).getName());
> }
> }
>
> $ /usr/local/java/bin/java -cp . filename "~noel/filename.java"
> ~noel/filename.java
> ~noel
> filename.java
> $ /usr/local/java/bin/java -cp . filename "c:/frodo/filename.java"
> c:/frodo/filename.java
> c:/frodo
> filename.java
> $ /usr/local/java/bin/java -cp . filename "share:/frodo/filename.java"
> share:/frodo/filename.java
> share:/frodo
> filename.java
> $ /usr/local/java/bin/java -cp . filename
> "//myserve/share/frodo/filename.java"
> /myserve/share/frodo/filename.java
> /myserve/share/frodo
> filename.java
> $ /usr/local/java/bin/java -cp . filename
> "\\myserve/share/frodo/filename.java"
> \myserve/share/frodo/filename.java
> \myserve/share/frodo
> filename.java
>
> OK, so java.io.File has some issues with UNC names on linux. Let's check
> Windows:
>
> > java -cp . filename "//myserve/share/frodo/filename.java"
> \\myserve\share\frodo\filename.java
> \\myserve\share\frodo
> filename.java
>
> > java -cp . filename "\\myserve\share\frodo\filename.java"
> \\myserve\share\frodo\filename.java
> \\myserve\share\frodo
> filename.java
>
> Works fine.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [PATH]FileUpload fix for filename for msiexplorer
Posted by "Noel J. Bergman" <no...@devtech.com>.
> FileUpload should not be in the business of deciding, on behalf of its
> client, how to interpret the content of fields uploaded by the browser.
+1
> > Method getName() in DefaultFileItem.java class when used with
> > msiexplorer 5/6 returns a filename with the whole client's
> > filesystem path which creates a problem when you want to save
> > the file on a server's filesystem.
What if I were storing information in a database, and wanted to preserve the
client's fields, or had some other need for the path?
What guarantee is there that the filename, even without the path, is valid
for the server? What if the client OS uses a different set of allowable
symbols? What if I already have a file of that name from another user?
What if ... ? Simply stripping the path from the name isn't going to
address the problem.
Besides which, this functionality is already in java.io.File:
import java.io.File;
public class filename {
public static void main(String[] args) {
System.out.println(new File(args[0]).getPath());
System.out.println(new File(args[0]).getParent());
System.out.println(new File(args[0]).getName());
}
}
$ /usr/local/java/bin/java -cp . filename "~noel/filename.java"
~noel/filename.java
~noel
filename.java
$ /usr/local/java/bin/java -cp . filename "c:/frodo/filename.java"
c:/frodo/filename.java
c:/frodo
filename.java
$ /usr/local/java/bin/java -cp . filename "share:/frodo/filename.java"
share:/frodo/filename.java
share:/frodo
filename.java
$ /usr/local/java/bin/java -cp . filename
"//myserve/share/frodo/filename.java"
/myserve/share/frodo/filename.java
/myserve/share/frodo
filename.java
$ /usr/local/java/bin/java -cp . filename
"\\myserve/share/frodo/filename.java"
\myserve/share/frodo/filename.java
\myserve/share/frodo
filename.java
OK, so java.io.File has some issues with UNC names on linux. Let's check
Windows:
> java -cp . filename "//myserve/share/frodo/filename.java"
\\myserve\share\frodo\filename.java
\\myserve\share\frodo
filename.java
> java -cp . filename "\\myserve\share\frodo\filename.java"
\\myserve\share\frodo\filename.java
\\myserve\share\frodo
filename.java
Works fine.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PATH]FileUpload fix for filename for msiexplorer
Posted by Martin Cooper <ma...@apache.org>.
FileUpload should not be in the business of deciding, on behalf of its
client, how to interpret the content of fields uploaded by the browser.
Its function is to parse the request into fields which can be accessed by
the client, and it is up to the client to decide how to process those
fields.
In particular, FileUpload is not a browser compatibility layer, and I, for
one, am not interested in incorporating this type of functionality. To do
so is to make potentially invalid assumptions about what the client wants
of it.
--
Martin Cooper
On Sat, 28 Jun 2003, maciek wrote:
> Method getName() in DefaultFileItem.java class when used with
> msiexplorer 5/6 returns a filename with the whole client's filesystem
> path which creates a problem when you want to save the file on a
> server's filesystem. I have chanaged the implementation of the getName()
> method to strip the path information from the filename.Below is my
> proposed implementation for getName() method:
>
> public String getName()
> {
>
> if(fileName.lastIndexOf("\\") != -1){
>
> return fileName.substring(fileName.lastIndexOf("\\") + 1);
>
> }else{
>
> return fileName;
> }
> }
>
> I have attached the fileName_fix_forMSIE.txt patch file.
>
> I have rebuild the entire source code to create a new jar and tested it
> with Tomcat and Resin. It works now with MSIE. A simple call to
> item.getName() returns only filename where item is of type FileItem.
>
> I think that it would be a better idea to change the implementation of
> the method without breaking of the FileUpload component interface than
> letting web developers to take care of the problem inside a jsp file.
> I think users of the component should use the method transparently
> without worrying about the possible problem with MSIE with the guarantee
> that ONLY filename will be returned from getName() method.
> Regards,
> Maciej Brodala
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PATH]FileUpload fix for filename for msiexplorer
Posted by maciek <ma...@pb-network.com>.
I have used gedit text editor that comes with RedHat7.3 distribution.
On Sat, 2003-06-28 at 15:33, Tetsuya Kitahata wrote:
>
> Okay, thank you.
>
> Well then,
> what (text editor) did you use to create/modify the
> 'DefaultFileItem.java' file?
>
> Sincerely,
>
> -- Tetsuya (tetsuya@apache.org)
>
> P.S. This question above is not just out of curiosity. Very sorry
> if you felt irritated.
>
> ---------------------------------------------------------------------
>
> On 28 Jun 2003 15:10:53 -0400
> (Subject: Re: [PATH]FileUpload fix for filename for msiexplorer)
> maciek <ma...@pb-network.com> wrote:
>
> > I did it on RedHat7.3 with the following command:
> > diff -u DefaultFileItem.java.orig DefaultFileItem.java >>
> > FileName_fix_forMSIE.txt
> > Regards,
> > maciej
> >
> > On Sat, 2003-06-28 at 14:57, Tetsuya Kitahata wrote:
> > >
> > > It seems that your [patch] (attachment file) has an extra carriage
> > > return CR added: 0D0D0A (CRCRLF: Two ASCII carriage returns and
> > > a line feed) instead of 0D0A (CRLF).
> > >
> > > Needless to say, "diff -u" would make redundant patch because
> > > "diff" compares '0D0D0A' and '0D0A'.
> > >
> > > How did you make this patch? (What kind of tool/editor did you use?)
> > >
> > > Sincerely,
> > >
> > > -- Tetsuya (tetsuya@apache.org)
> > >
> > > P.S. I think recently "0D0D0A"s are scattered here and there
> > > in jakarta...
> <snip/>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PATH]FileUpload fix for filename for msiexplorer
Posted by Tetsuya Kitahata <te...@apache.org>.
Okay, thank you.
Well then,
what (text editor) did you use to create/modify the
'DefaultFileItem.java' file?
Sincerely,
-- Tetsuya (tetsuya@apache.org)
P.S. This question above is not just out of curiosity. Very sorry
if you felt irritated.
---------------------------------------------------------------------
On 28 Jun 2003 15:10:53 -0400
(Subject: Re: [PATH]FileUpload fix for filename for msiexplorer)
maciek <ma...@pb-network.com> wrote:
> I did it on RedHat7.3 with the following command:
> diff -u DefaultFileItem.java.orig DefaultFileItem.java >>
> FileName_fix_forMSIE.txt
> Regards,
> maciej
>
> On Sat, 2003-06-28 at 14:57, Tetsuya Kitahata wrote:
> >
> > It seems that your [patch] (attachment file) has an extra carriage
> > return CR added: 0D0D0A (CRCRLF: Two ASCII carriage returns and
> > a line feed) instead of 0D0A (CRLF).
> >
> > Needless to say, "diff -u" would make redundant patch because
> > "diff" compares '0D0D0A' and '0D0A'.
> >
> > How did you make this patch? (What kind of tool/editor did you use?)
> >
> > Sincerely,
> >
> > -- Tetsuya (tetsuya@apache.org)
> >
> > P.S. I think recently "0D0D0A"s are scattered here and there
> > in jakarta...
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PATH]FileUpload fix for filename for msiexplorer
Posted by maciek <ma...@pb-network.com>.
I did it on RedHat7.3 with the following command:
diff -u DefaultFileItem.java.orig DefaultFileItem.java >>
FileName_fix_forMSIE.txt
Regards,
maciej
On Sat, 2003-06-28 at 14:57, Tetsuya Kitahata wrote:
>
> It seems that your [patch] (attachment file) has an extra carriage
> return CR added: 0D0D0A (CRCRLF: Two ASCII carriage returns and
> a line feed) instead of 0D0A (CRLF).
>
> Needless to say, "diff -u" would make redundant patch because
> "diff" compares '0D0D0A' and '0D0A'.
>
> How did you make this patch? (What kind of tool/editor did you use?)
>
> Sincerely,
>
> -- Tetsuya (tetsuya@apache.org)
>
> P.S. I think recently "0D0D0A"s are scattered here and there
> in jakarta...
>
> ---------------------------------------------------------------------
>
> On 28 Jun 2003 13:46:31 -0400
> (Subject: [PATH]FileUpload fix for filename for msiexplorer)
> maciek <ma...@pb-network.com> wrote:
>
> > Method getName() in DefaultFileItem.java class when used with
> > msiexplorer 5/6 returns a filename with the whole client's filesystem
> > path which creates a problem when you want to save the file on a
> > server's filesystem. I have chanaged the implementation of the getName()
> > method to strip the path information from the filename.Below is my
> > proposed implementation for getName() method:
> >
> > public String getName()
> > {
> >
> > if(fileName.lastIndexOf("\\") != -1){
> >
> > return fileName.substring(fileName.lastIndexOf("\\") + 1);
> >
> > }else{
> >
> > return fileName;
> > }
> > }
> >
> > I have attached the fileName_fix_forMSIE.txt patch file.
> >
> > I have rebuild the entire source code to create a new jar and tested it
> > with Tomcat and Resin. It works now with MSIE. A simple call to
> > item.getName() returns only filename where item is of type FileItem.
> >
> > I think that it would be a better idea to change the implementation of
> > the method without breaking of the FileUpload component interface than
> > letting web developers to take care of the problem inside a jsp file.
> > I think users of the component should use the method transparently
> > without worrying about the possible problem with MSIE with the guarantee
> > that ONLY filename will be returned from getName() method.
> > Regards,
> > Maciej Brodala
> >
> >
>
> -----------------------------------------------------
> Tetsuya Kitahata -- Terra-International, Inc.
> E-mail: kitahata@bb.mbn.or.jp : tetsuya@apache.org
> http://www.terra-intl.com/
> (Apache Jakarta Translation, Japanese)
> http://jakarta.terra-intl.com/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PATH]FileUpload fix for filename for msiexplorer
Posted by Tetsuya Kitahata <te...@apache.org>.
It seems that your [patch] (attachment file) has an extra carriage
return CR added: 0D0D0A (CRCRLF: Two ASCII carriage returns and
a line feed) instead of 0D0A (CRLF).
Needless to say, "diff -u" would make redundant patch because
"diff" compares '0D0D0A' and '0D0A'.
How did you make this patch? (What kind of tool/editor did you use?)
Sincerely,
-- Tetsuya (tetsuya@apache.org)
P.S. I think recently "0D0D0A"s are scattered here and there
in jakarta...
---------------------------------------------------------------------
On 28 Jun 2003 13:46:31 -0400
(Subject: [PATH]FileUpload fix for filename for msiexplorer)
maciek <ma...@pb-network.com> wrote:
> Method getName() in DefaultFileItem.java class when used with
> msiexplorer 5/6 returns a filename with the whole client's filesystem
> path which creates a problem when you want to save the file on a
> server's filesystem. I have chanaged the implementation of the getName()
> method to strip the path information from the filename.Below is my
> proposed implementation for getName() method:
>
> public String getName()
> {
>
> if(fileName.lastIndexOf("\\") != -1){
>
> return fileName.substring(fileName.lastIndexOf("\\") + 1);
>
> }else{
>
> return fileName;
> }
> }
>
> I have attached the fileName_fix_forMSIE.txt patch file.
>
> I have rebuild the entire source code to create a new jar and tested it
> with Tomcat and Resin. It works now with MSIE. A simple call to
> item.getName() returns only filename where item is of type FileItem.
>
> I think that it would be a better idea to change the implementation of
> the method without breaking of the FileUpload component interface than
> letting web developers to take care of the problem inside a jsp file.
> I think users of the component should use the method transparently
> without worrying about the possible problem with MSIE with the guarantee
> that ONLY filename will be returned from getName() method.
> Regards,
> Maciej Brodala
>
>
-----------------------------------------------------
Tetsuya Kitahata -- Terra-International, Inc.
E-mail: kitahata@bb.mbn.or.jp : tetsuya@apache.org
http://www.terra-intl.com/
(Apache Jakarta Translation, Japanese)
http://jakarta.terra-intl.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org