cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: [patch] use only basename in "filename" attribute in -F post

From: Fedor Karpelevitch <fedor_at_karpelevitch.net>
Date: Tue, 28 Sep 2004 06:17:46 -0700

Daniel Stenberg wrote:
> On Mon, 27 Sep 2004, Fedor Karpelevitch wrote:
> > currently curl by default sets "filename" attribute for an
> > uploaded file to whatever was specified on command line.
>
> Correct.
>
> > RFC is not entirely clear (to me) regarding what exactly should
> > be put in this field
>
> To me it is clear. It doesn't dictate details such as this.

well, it says that there should be the "filename", and interpretation
of that term is left to the reader. It makes sense to interpret it as
the name of the file itself as opposed to the "filepath".

>
> > browsers I checked (IE, mozilla, konqueror) seem to agree in
> > putting just the basename of the file there.
>
> Are you _sure_ that all browsers do this on all operating systems
> no matter what path you use? I am very sure at least some browsers
> on some operating systems have passed along the full path at some
> point. (Since I spent a few days debugging exaclty such a case a
> few years back when I introduced the way to set only the file
> name.)

I am not sure about _all_ browsers on _all_ OSes, but I believe my
sample to be good enough. I checked IE (on windows), Konqueror (on
Linux) and Firefox (on both). They all have independent codebases so
if they all agree on something there may just be a point. Also if you
think about it:

 - email clients similarly only specify filenames (not paths) for
attached files
 - for server your local path is most likely useless, so it would need
to strip it off somehow. It would need to know (or guess) your
platform to know which delimeters to look for when parsing.
 - it may be considered a security risk to disclose local directory
structure to the remote server.

>
> > Attached is my patch to fix this problem (works for me). I am not
> > sure it is done right (it's been several years since I wrote
> > anything in C), but you get the idea at least. Let me know if
> > this patch can be accepted.
>
> libgen.h is not a very portable header to use unconditionally and
> neither is basename(). They are both present in IEEE Std
> 1003.1-2001 but not ANSI C and thus not likely to be present on all
> systems that (lib)curl builds on.

that's what I suspected. There is another declaration for basename()
in string.h, is that more portable?

>
> Besides this, I think I'd rather document the existing
> functionality of curl_formadd() and family, and have the -F
> approach fixed for this in the app code.

Is there currently a way to pass 'showfilename' from the app? I did
not see that (at least in the docs), so I assumed it is not possible
to pass it from the app. Anyway it still seems to me that it would be
better if default behaviour of the library be more "correct" (I am
pretty convinced at this point that passing basename _is_ really the
"correct" behaviour). Having to pass additional parameters just to
get it to do the "right thing" does not seem right...

Fedor.

-- 
The Thought Police are here.  They've come
To put you under cardiac arrest.
And as they drag you through the door
They tell you that you've failed the test.
  -- Buggles, "Living in the Plastic Age"

  • application/pgp-signature attachment: stored
Received on 2004-09-29