On 22/06/2009, sebb <seb...@gmail.com> wrote: > On 22/06/2009, Siegfried Goeschl <siegfried.goes...@it20one.at> wrote: > > Hi Mark, > > > > the intention is to CLEARLY use a invalid URI/URL to cause some > > exceptions during regression tests - during the last RC we had issues > > with OpenDNS and using ".invalid" was the agreed workaround (which did > > not work either) > > > The use of the invalid TLD is necessary to ensure that the URL really is bad. > The URLs used previously did not exist, but could possibly have been created. > Testing with OpenDNS effectively created them, revealing the test bug. > > It's unfortunate that OpenDNS does not adhere to the RFC.
I've sent them a support request about their response to .invalid TLD hosts. They currently report "non-existent domain" for .localhost; they should definitely be doing this for .invalid, and probably .test and .example as well. > > > See http://tools.ietf.org/html/rfc2606 > > > > === QUOTE from RFC2006 === > > > > ".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. > > > > === END OF QUOTE === > > > > Cheers, > > > > > > Siegfried Goeschl > > > > > > Mark Struberg wrote: > > > Hi Ziggi! > > > > > > > > >> +) using "http://example.invalid"; for a bad url > > >> > > > > > > hmm, sorry if I missed the point, but what exactly is wrong with that > very URI? The 'invalid' tld? What about 'local' URIs for e.g. company > internal resources? Remember our maven.intern ... > > > > > > LieGrue, > > > mark > > > > > > --- Siegfried Goeschl <siegfried.goes...@it20one.at> schrieb am Mo, > 22.6.2009: > > > > > > > > >> Von: Siegfried Goeschl <siegfried.goes...@it20one.at> > > >> Betreff: [VOTE] Release commons-email-1.2 based on RC2 > > >> An: dev@commons.apache.org > > >> Datum: Montag, 22. Juni 2009, 0:23 > > >> Hi folks, > > >> > > >> I would like to call a vote for releasing commons-email-1.2 > > >> based on RC2. > > >> > > >> This release candidate has the following changes compared > > >> to RC1 > > >> > > >> +) using "http://example.invalid"; for a bad url > > >> +) avoid using java.net.URL.equals(Object) which blocks to > > >> do domain name resolution > > >> +) removed all of the M1 left-overs and updated the > > >> assembly descriptors > > >> +) added the minimum JDK requirement to the index page > > >> +) the regression tests now work without internet > > >> connectivity > > >> > > >> > > >> Tag: > > >> > > >> https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_2 > > >> > > >> Site: > > >> > > >> http://people.apache.org/builds/commons/email/1.2/RC2/site/index.html > > >> > > >> Binaries: > > >> > > >> > http://people.apache.org/builds/commons/email/1.2/RC2/staged/commons-email/commons-email/1.2/ > > >> > > >> [ ] +1 release it > > >> [ ] +0 go ahead I don't care > > >> [ ] -1 no, do not release it because > > >> > > >> Thanks in advance > > >> > > >> Siegfried Goeschl > > >> > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > >> > > >> > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
