On Tue, 28 Sep 2004, Fedor Karpelevitch wrote:

>> 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".

As has said before, other user-agents have sent the full path in there in the
past, so I'm not alone in my interpretation of this. We even had to fake the
file name to prefix it with "C:\\" once to have a server accept it.

Besides, since file names can consist of basically anything in the local side,
the server still needs to deal with weird file names. Perhaps my OS supports
slashes, newlines, colons or whatever in file names. The server just cannot
tell for sure if I give it a full path, a partial path or just a plain file
name.

Thus, I don't think this is an issue about what RFC1867 allows or not. It is a
question what we believe (lib)curl should do.

[basename]

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

We need to add a check to configure that checks for the function (and the
header file) and provide our own version of it for systems that don't feature
it.

I also noticed that there are two versions of it in Linux systems, one POSIX
and one GNU style...

> 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...

I'm convinced now as well. Let's fix this in the library as you started out,
and if anyone wants to bring back the old behaviour it is still possible with
the CURLFORM_FILENAME option.

-- 
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html