On 05/08/2009, John Napiorkowski <jjn1...@yahoo.com> wrote: > > > > > ----- Original Message ---- > > From: sebb <seb...@gmail.com> > > To: John Napiorkowski <jjn1...@yahoo.com> > > Cc: libwww@perl.org > > > Sent: Tuesday, August 4, 2009 10:08:49 PM > > Subject: Re: regarding RT#36554 > > > > > On 05/08/2009, John Napiorkowski wrote: > > > > > > > > > > > > > > > ----- Original Message ---- > > > > From: Tatsuhiko Miyagawa > > > > > To: John Napiorkowski > > > > Cc: libwww@perl.org > > > > Sent: Tuesday, August 4, 2009 9:16:31 PM > > > > Subject: Re: regarding RT#36554 > > > > > > > > I believe this is fixed by my patch and released as 1.38. > > > > > http://github.com/gisle/uri/commit/4af5412726c6f719d76ffb666054a72c9cd2c492 > > > > http://cpansearch.perl.org/src/GAAS/URI-1.38/Changes > > > > > > > > > I can verify that a bug of some sort in that area of the code still > exists. > > Also, a quick glance at the cpan test reports will show 9 errors in the > same > > test as the one I am getting. Since not all those tests are giving > details I > > cannot be 100% certain but it stands to reason. > > > > > > The patch to this test that found it's way into 1.38 helped one case, > but not > > another. And is seems it's affecting people. > > > > > > Is the best thing for me to just open a new RT issue? I just thought > that > > wasn't right, since I thought it was a duplicate bug and generally it's > best not > > to report dups as new bugs. > > > > > > If you read to the bottom of the RT I try to give more detailed error > outputs > > and diagnostics, and where I looked in the code to try and understand what > the > > test was trying to do. > > > > Note that example.xyz is _not_ guaranteed to be invalid for evermore. > > It's possible (but rather unlikely) that xyz could become a TLD. > > > > The only TLD that is never supposed to exist is ".invalid", see RFC > > 2606 which says: > > > > ".invalid" is intended for use in online construction of domain > > names that are sure to be invalid and which it is obvious at a > > glance are invalid. > > > > Unfortunately, OpenDNS does not honour this. > > [I've sent in a bug report about this; maybe more people should do so!] > > > > Note that you can disable OpenDNS resolution of unknown hosts if you > > sign up for an account (but that should not be necessary for > > .invalid). > > > > > Well, there's definitely lots that can go wrong in these tests, since they > all rely on an external system to function. However we have been reasonable > agile and patched the worst. At some point www.perl.com/camel.gif will > go an we will need to fix that, for example. >
True, but if the code uses ".invalid" then you know it is future-proof - and it is clearer what the intention is. Furthermore, OpenDNS may (should) stop resolving ".invalid", but it's highly unlikely that they will stop resolving other non-existent domains, because that is one way they try to make money. > john > > > > > John > > > > > > > > > > > On Tue, Aug 4, 2009 at 6:11 PM, John Napiorkowskiwrote: > > > > > > > > Hi, > > > > > > > > > > This is a message regarding RT36554 (also at > > > > http://rt.cpan.org/Public/Bug/Display.html?id=36554) This is a quasi > bug > > in one > > > > of the test cases (t/heuristics.t) that causes a single test to fail > if > > your > > > > local internet service provider is playing silly buggers with failed > host > > name > > > > lookups. Although I discuss the problem in more detail over on the > > referenced > > > > link, the short story is that some internet providers return a > positive > > result > > > > for 'www.perl.bz' even though that domain does not really exist. It > > appears > > > > that some providers use the opportunity of a failed hostname lookup to > > return > > > > some 'helpful' adverstivements. This is very common among a lot of > > internet > > > > providers targeting private homes. > > > > > > > > > > As a result URI fails to install, even though this test failure is > really > > not > > > > related to any problems with URI. However, it seems that 9 out of > the 11 > > > > reported test failures are related to this problem. The fix is > trivial and > > I > > > > have posted it on a fork of the URI git repository over at: > > > > http://gitorious.org/~jnapiorkowski/perl-uri/uri-heuristicstest-fix > > > > > > > > > > You can also see the exact diff of this proposed patch over at: > > > > > > > http://gitorious.org/~jnapiorkowski/perl-uri/uri-heuristicstest-fix/commit/b18366e443138fe41125d659e9572a0e90392c87 > > > > > > > > > > I sent in a merge request to the URI git mainline, but it was > rejected. > > The > > > > reason given was that no one had heard of this problem. Please spend > a > > moment > > > > looking at the RT mentioned and you can see this problem has been > reported > > for > > > > over a year. > > > > > > > > > > If I am not following the correct procedure for submitting bugs and > > patches, > > > > please let me know. Right now this problem is affecting my work > deployment > > and > > > > every time I have to tell the local admin to force install URI before > > installing > > > > Catalyst this gets flagged and I have to answer why I am doing new > > development > > > > in Perl when it's so buggy :) > > > > > > > > > > Thanks! > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Tatsuhiko Miyagawa > > > > > > > > > > > > > > > > > > > >
