Skip Menu |

This queue is for tickets about the WWW-Curl CPAN distribution.

Report information
The Basics
Id: 41425
Status: resolved
Priority: 0/
Queue: WWW-Curl

People
Owner: Nobody in particular
Requestors: NeoARN [...] ya.ru
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Subject: Test "Curl1 handle fails as expected" may fail on Windows and MacOS
In my corporate network DHCP reports default domain and our DNS resolves not known names to valid IP. This is needed to show custom 404 error to those who misprinted in URL. So, "error:bad-url" transforms into "error:bad-url.my-domain.org" and successfully resolves into existing address. Moreover, URIs with [*#$%/;] etc, and even with quotes are also valid and successfully resolved. Admittedly, curl on different Linuxes and FreeBSD does not try to get such URIs (but they still resolved by "host"). This behavior of curl can be fully reproduced on any Windows and MacOS. To reproduce this you may add lycos.com or h1.org or livejournal.com as default search domain. All of them resolve not known names to default IP.
Subject: Re: [rt.cpan.org #41425] Test "Curl1 handle fails as expected" may fail on Windows and MacOS
Date: Thu, 04 Dec 2008 22:48:38 +1100
To: bug-WWW-Curl [...] rt.cpan.org
From: Cris Bailiff <c.bailiff [...] awayweb.com>
Romain, From your description, I believe you are reporting what you think is a bug in the curl program and/or the libcurl library. The CPAN bug tracker is for tracking bugs in perl modules, and you have filed this under the WWW::Curl module, which is a 'wrapper' for libcurl to allow it to be used in perl programs. WWW::Curl doesn't control the behaviour of libcurl, so I think you need to report your issue to the libcurl developers at curl.haxx.se If you think your problem is with the perl interface, can you please respond with more detail and/or an example perl script using WWW::Curl which shows the behaviour you think is faulty? Cheers, Cris
From: NeoARN [...] ya.ru
On Thu Dec 04 06:50:57 2008, c.bailiff@awayweb.com wrote: Show quoted text
> If you think your problem is with the perl interface, can you please > respond with more detail and/or an example perl script using WWW::Curl > which shows the behaviour you think is faulty?
I think, that curl works right in this case, cause whole system works such way. Windows and MacOS believe that "error:bad-url" is correct URL and so does curl. That's why I think that it is incorrect to expect error from curl when you ask it to get valid URL.
From: NeoARN [...] ya.ru
I'll specify: It's all about test 18twinhandles.t: my $curl1 = WWW::Curl::Easy->new(); #...skip.. $curl1->setopt(CURLOPT_URL, "error:bad-url"); #...skip... my $code1=$curl1->perform(); ok($code1 != 0, "Curl1 handle fails as expected"); I guess, that getting success from such call is not an error.
On Thu Dec 04 07:03:34 2008, nARN wrote: Show quoted text
> I think, that curl works right in this case, cause whole system works > such way. Windows and MacOS believe that "error:bad-url" is correct URL > and so does curl. That's why I think that it is incorrect to expect > error from curl when you ask it to get valid URL.
Technically yes, "error:bad-url" is a valid uri as defined by RFC 2396, however curl requires a properly formatted uri AND that the given protocol be supported by the currently compiled version of libcurl, so this string not throwing any error messages is definitely a bug. I will modify the test to include a fully invalid uri though and add another test for a valid uri to a nonexistent protocol with maybe a SKIP check on it for Windows and MacOS if it turns out that curl is lead to believe by the OS that every protocol is valid for some reason - which I doubt is the case since curl should be checking it's own list of supported protocols, not the OS's.
This bug is now fixed in 4.06.