>
> > OK, this makes sense - no more need to have code in http.c which
relies on
> > formdata.c internals.
> >
> > Here is the new version of the patch.
>
> Goodie, this looks better. I'm curious on your check for ';' in the
provided
> custom content type. Can you tell me a case where you actually need/want

> libcurl to add a comma to the line instead of a semicolon?
>
> RFC1867 does indeed use a comma in their example Content-Type, but
libcurl
> uses a straight semicolon and has always done so (as we've mimiced the
> browsers who used semilcolon back in the days when I added this and I
guess
> they still do).

Right, i am completely wrong... I wrote this from wrong memories and a
truncated paper print,
and once my mime parser accepted the post i stopped thinking to the
syntax...

I have the feeling that examples in RFCs are often unreliable, e.g. at
http://www.ietf.org/rfc/rfc1872
there is an example content-type with just a space as a separator, before
the start-info.

However in the BNF the parameter separator is always specified as ';',
to be consistent with MIME section 5.1.
Here this is an HTTP header, so lexical rules are different from MIME, but
the syntax is the same.

I have fixed the patch, here it is (with http.c.diff unchanged).

Thanks a lot for your check,
Yves.

>
> Oh, and please keep source lines shorter than 80 columns to remain "curl

> style".
>