Re: regarding RT#36554

On 05/08/2009, John Napiorkowski <[email protected]> wrote:
>
>
>
>
>  ----- Original Message ----
>  > From: sebb <[email protected]>
>  > To: John Napiorkowski <[email protected]>
>  > Cc: [email protected]
>
> > 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: [email protected]
>  > >  > 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
>  > >
>  > >
>  > >
>  > >
>  > >
>
>
>
>
>