On Apr 3, 12:10, Daniel Stenberg wrote:
>Thanks for your patch!
>
>This is not a flaw in (lib)curl, this is a bug in the perl package you're
>using. RFC2046, section 5.1.1, page 22 clearly states that both these
>characters are legal in boundary separators. In fact, there are a whole range
>of other characters that are also legal and will cause the same problems for
>that perl script (since characters such as ( and ), ? etc also are
>regex-letters).
>
>It seems someone was being ignorant of the standards when writing that code.
>:-)
>
>Also AFAIK, '/' is not used in regexes...

It is (in a sense), because Perl regex'es are usually between '/' boundaries
(e.g. "if (/(\d+)$other_pattern/) $value=$1;", which BTW also show the
type of code that exists in that CGI_Lite Perl package. $other_pattern would
be that form separator string.)

>> The below fix illustrates the problem, but maybe there is a better way.
>> It works, anyway.
>
>While I'll accept this patch as it does no harm and increases compatibility
>with some web scripts "out there", I strongly urge you to take this issue to
>the author of that perl package.

The problem is that there are a bunch of sites out there which uses CGI_Lite
(it can be simpler to use than the "standard" Perl CGI package for some
things), and usually it works fine as far as those web site authors are
concerned.
This is of course because Netscape etc. creates simpler form separators
than curl does. I will try to track down the CGI_Lite author(s) and send
a patch for it, but as usual there is the problem of getting users out there
to update..

Cheers,
Tor Arntsen
(I have now joined the curl-library mailing list, btw)
Received on 2002-04-03