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