On 05/08/2009, John Napiorkowski <jjn1...@yahoo.com> wrote:
>
>
>
>
> ----- Original Message ----
> > From: Tatsuhiko Miyagawa <miyag...@gmail.com>
> > To: John Napiorkowski <jjn1...@yahoo.com>
> > 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).
> 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
>
>
>
>
>
