You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by David Wall <d....@computer.org> on 2006/04/08 00:49:19 UTC
FileItem.getName() (v1.1) always lowercase?
It seems that when I upload using IE or Firefox, the file name is always
lowercase. Is that the case, and if so, why?
I also noted that IE was uploading with the full path to the file, while
Firefox just sent the file name. The full path seems like an unexpected
amount of info leakage when sending a file.
Thanks,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [fileupload] FileItem.getName() IE prefix
Posted by Henri Yandell <fl...@gmail.com>.
On 4/13/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Martin Cooper wrote:
> > Should I be quoting examples of where people have suggested enhancements to
> > Commons IO that you have claimed are out of scope for that component? I seem
> > to remember essentially the same discussion coming up there. Certain methods
> > _could_ be added, but were not. Why?
>
> Scope is always a difficult call. [fileupload] is lucky on this front as
> its scope is naturally much better defined than [io]'s 'stuff that helps
> with io'.
>
> IMHO, this is a repetitive problem that [fileupload] could address
> without a big impact and without further scope creep. But I read a -1
> between the lines, so I'll stop talking :-)
Opening this up again as I want to put it to bed before a 1.1.1/1.2
release. I'm +1 to the change, but I don't see an obvious direction
for applying the change.
I think it's valuable for the most commonly used method in FileUpload
to get a name, to get it uniformally across browsers - while another
less commonly used method would offer up the real String sent by the
browser.
So if I had my druthers, I'd change getName (which I understand we are
tied to for an Activation infterface) functionality and add a
getBrowserSpecifiedName. However, that's an evil thing to do to the
user; though possibly we could do so in a FileUpload 2.0.
My next thought was to add a getFile method which returned a
java.io.File - people could then do what they wanted with that.
However even though that's possible, it would be a bit confusing as it
would imply the File is present on the server.
So next up is to add a new method name for the uniform filename.
getBasename clashes with a function of the same name but different
functionality in Commons IO, in IO it returns the filename without the
extension whereas I'd presume we'd want the extension here.
The naming problem here is that we want it to be noticeably different
from 'getName', and yet also it should be noticeably the better method
to be calling. These clash and leave names like getFilename too
confusing and names like getUniformFilename too disctinct.
----
So I see three options:
1) [FileUpload 2.0] Make getName() behave uniformally and add a method
to get the real String.
2) [FileUpload 1.1.1] Stick to the javadoc comment.
3) [FileUpload 1.2] Come up with a new method name for the uniform method name.
Any views?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [fileupload] FileItem.getName() IE prefix
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Martin Cooper wrote:
> Should I be quoting examples of where people have suggested enhancements to
> Commons IO that you have claimed are out of scope for that component? I seem
> to remember essentially the same discussion coming up there. Certain methods
> _could_ be added, but were not. Why?
Scope is always a difficult call. [fileupload] is lucky on this front as
its scope is naturally much better defined than [io]'s 'stuff that helps
with io'.
IMHO, this is a repetitive problem that [fileupload] could address
without a big impact and without further scope creep. But I read a -1
between the lines, so I'll stop talking :-)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [fileupload] FileItem.getName() IE prefix
Posted by Martin Cooper <ma...@apache.org>.
On 4/12/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
>
> Martin Cooper wrote:
> >>The point is not that this code is onerous, but that it is knowledge
> >>about fileuploading that we have not encapsulated in [fileupload].
> >
> > Because it was specifically not intended to be addressed by FileUpload.
>
> But that doesn't answer why it can't.
Should I be quoting examples of where people have suggested enhancements to
Commons IO that you have claimed are out of scope for that component? I seem
to remember essentially the same discussion coming up there. Certain methods
_could_ be added, but were not. Why?
--
Martin Cooper
This is a component to assist with
> file uploading. This is a known problem with file uploading. It comes up
> reapeatedly in user queries. Surely this points to a missing method.
>
> Is the problem the fact that FileItem is an interface and thus can't be
> changed?
>
> >> As a user of [fileupload] I should be presented with the fact that I
> >>have to make a choice in the API. At the very least, the javadoc for
> >>getName() should provide a full description of the problem.
> > You mean like this?
> >
> http://jakarta.apache.org/commons/fileupload/apidocs/org/apache/commons/fileupload/FileItem.html#getName()
>
> Yes. I looked in the disk package, where the text isn't present.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [fileupload] FileItem.getName() IE prefix
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Martin Cooper wrote:
>>The point is not that this code is onerous, but that it is knowledge
>>about fileuploading that we have not encapsulated in [fileupload].
>
> Because it was specifically not intended to be addressed by FileUpload.
But that doesn't answer why it can't. This is a component to assist with
file uploading. This is a known problem with file uploading. It comes up
reapeatedly in user queries. Surely this points to a missing method.
Is the problem the fact that FileItem is an interface and thus can't be
changed?
>> As a user of [fileupload] I should be presented with the fact that I
>>have to make a choice in the API. At the very least, the javadoc for
>>getName() should provide a full description of the problem.
> You mean like this?
> http://jakarta.apache.org/commons/fileupload/apidocs/org/apache/commons/fileupload/FileItem.html#getName()
Yes. I looked in the disk package, where the text isn't present.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [fileupload] FileItem.getName() IE prefix
Posted by Martin Cooper <ma...@apache.org>.
On 4/11/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
>
> Martin Cooper wrote:
> > Well, they've already got Commons IO, since FileUpload depends on that,
> and
> > that has FileNameUtils.getName() to get just the file name, so do we
> really
> > need to add another method in FileUpload that just wraps that call?
> >
> > String filename = FileNameUtils.getName(item.getName());
> > instead of:
> > String file name = item.getName();
> > doesn't seem so onerous.
>
> The point is not that this code is onerous, but that it is knowledge
> about fileuploading that we have not encapsulated in [fileupload].
Because it was specifically not intended to be addressed by FileUpload.
As a user of [fileupload] I should be presented with the fact that I
> have to make a choice in the API. At the very least, the javadoc for
> getName() should provide a full description of the problem.
You mean like this?
http://jakarta.apache.org/commons/fileupload/apidocs/org/apache/commons/fileupload/FileItem.html#getName()
--
Martin Cooper
I think I prefer getNameNoPath() as the method name. The reason is that
> it will appear next to getName() in IDE auto-complete, thus causing
> casual users to stop and think.
>
> I volunteer to code this (or apply an external patch ;-) if it won't be
> -1'ed.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [fileupload] FileItem.getName() IE prefix
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Martin Cooper wrote:
> Well, they've already got Commons IO, since FileUpload depends on that, and
> that has FileNameUtils.getName() to get just the file name, so do we really
> need to add another method in FileUpload that just wraps that call?
>
> String filename = FileNameUtils.getName(item.getName());
> instead of:
> String file name = item.getName();
> doesn't seem so onerous.
The point is not that this code is onerous, but that it is knowledge
about fileuploading that we have not encapsulated in [fileupload].
As a user of [fileupload] I should be presented with the fact that I
have to make a choice in the API. At the very least, the javadoc for
getName() should provide a full description of the problem.
I think I prefer getNameNoPath() as the method name. The reason is that
it will appear next to getName() in IDE auto-complete, thus causing
casual users to stop and think.
I volunteer to code this (or apply an external patch ;-) if it won't be
-1'ed.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [fileupload] FileItem.getName() IE prefix
Posted by Martin Cooper <ma...@apache.org>.
On 4/8/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
>
> From commons-user:
> >>True, but I noted that O'Reilly's version just added this snippet to
> >>remove any trailing / or \:
> >
> > Right. The Commons FileUpload philosophy, though, is to give you exactly
> > what the browser sent, no more and no less. It's not up to FileUpload to
> > determine what the caller wants - some callers may want or need the
> extra
> > information if it's available.
>
> Thats probably the right philosopy for getName(), but shouldn't we have
> a getBaseName() or similarly named method _as_well_ that does the
> stripping of the IE rubbish?
Well, they've already got Commons IO, since FileUpload depends on that, and
that has FileNameUtils.getName() to get just the file name, so do we really
need to add another method in FileUpload that just wraps that call?
And if you think we do, what would we call it? You mentioned getBaseName(),
but there's a method in FileNameUtils with that name that does something
different, so I think that would be confusing.
At present we are forcing every user of [fileupload] to know this naming
> fact and write code to handle it, which surely goes against commons
> philosophy.
String filename = FileNameUtils.getName(item.getName());
instead of:
String file name = item.getName();
doesn't seem so onerous.
--
Martin Cooper
Stephen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
[fileupload] FileItem.getName() IE prefix
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From commons-user:
>>True, but I noted that O'Reilly's version just added this snippet to
>>remove any trailing / or \:
>
> Right. The Commons FileUpload philosophy, though, is to give you exactly
> what the browser sent, no more and no less. It's not up to FileUpload to
> determine what the caller wants - some callers may want or need the extra
> information if it's available.
Thats probably the right philosopy for getName(), but shouldn't we have
a getBaseName() or similarly named method _as_well_ that does the
stripping of the IE rubbish?
At present we are forcing every user of [fileupload] to know this naming
fact and write code to handle it, which surely goes against commons
philosophy.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: FileItem.getName() (v1.1) always lowercase?
Posted by Martin Cooper <ma...@apache.org>.
On 4/7/06, David Wall <d....@computer.org> wrote:
>
>
> >Yes, that is the case. It's a bug that has already been fixed. You can
> pick
> >up a nightly build if you need the fix; that's pretty safe, since nothing
> >else has changed since the 1.1 release.
> >
> >
> Thanks. Works fine.
>
> >I also noted that IE was uploading with the full path to the file, while
> >
> >
> >>Firefox just sent the file name. The full path seems like an unexpected
> >>amount of info leakage when sending a file.
> >>
> >>
> >
> >
> >That's not something that Commons FileUpload has any effect on. It's
> >entirely up to the browser to decide what to send. I agree with you that
> >it's more than I'd like to expose, but there's no way around it. Well, I
> >guess there is - don't use IE. ;-)
> >
> >
> True, but I noted that O'Reilly's version just added this snippet to
> remove any trailing / or \:
Right. The Commons FileUpload philosophy, though, is to give you exactly
what the browser sent, no more and no less. It's not up to FileUpload to
determine what the caller wants - some callers may want or need the extra
information if it's available.
--
Martin Cooper
// The filename may contain a full path. Cut to
> just the filename.
> int slash = Math.max(filename.lastIndexOf('/'),
> filename.lastIndexOf('\\'));
> if (slash > -1) {
> filename = filename.substring(slash + 1); //
> past last slash
> }
>
> Thanks,
> David
>
>
Re: FileItem.getName() (v1.1) always lowercase?
Posted by David Wall <d....@computer.org>.
>Yes, that is the case. It's a bug that has already been fixed. You can pick
>up a nightly build if you need the fix; that's pretty safe, since nothing
>else has changed since the 1.1 release.
>
>
Thanks. Works fine.
>I also noted that IE was uploading with the full path to the file, while
>
>
>>Firefox just sent the file name. The full path seems like an unexpected
>>amount of info leakage when sending a file.
>>
>>
>
>
>That's not something that Commons FileUpload has any effect on. It's
>entirely up to the browser to decide what to send. I agree with you that
>it's more than I'd like to expose, but there's no way around it. Well, I
>guess there is - don't use IE. ;-)
>
>
True, but I noted that O'Reilly's version just added this snippet to
remove any trailing / or \:
// The filename may contain a full path. Cut to
just the filename.
int slash = Math.max(filename.lastIndexOf('/'),
filename.lastIndexOf('\\'));
if (slash > -1) {
filename = filename.substring(slash + 1); //
past last slash
}
Thanks,
David
Re: FileItem.getName() (v1.1) always lowercase?
Posted by Martin Cooper <ma...@apache.org>.
On 4/7/06, David Wall <d....@computer.org> wrote:
>
> It seems that when I upload using IE or Firefox, the file name is always
> lowercase. Is that the case, and if so, why?
Yes, that is the case. It's a bug that has already been fixed. You can pick
up a nightly build if you need the fix; that's pretty safe, since nothing
else has changed since the 1.1 release.
I also noted that IE was uploading with the full path to the file, while
> Firefox just sent the file name. The full path seems like an unexpected
> amount of info leakage when sending a file.
That's not something that Commons FileUpload has any effect on. It's
entirely up to the browser to decide what to send. I agree with you that
it's more than I'd like to expose, but there's no way around it. Well, I
guess there is - don't use IE. ;-)
--
Martin Cooper
Thanks,
> David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>