Re: DNS Issues

Hello,

On 27-Oct-08, at 10:40 PM, . wrote:
> 500 Can't connect to k1t.net:80 (connect: Connection refused)
>
> If you made recent changes to your domain name (DNS) configuration,  
> you may also want to check that your domain records are correct, or  
> ask your hosting company to do so.
>
>
> This seems to only happen soon after DNS updates, so it's possible  
> W3C is w3.org is using an older cached address.

That's possible indeed. The validator's DNS cache, just as any  
computer's, tends to take up to a day to update.

One cool trick I would try, in that case, would be, instead of checking
http://www.example.org/
is to check
http://www.example.org./
(notice the dot)

Hope this helps,
--

-- 
olivier

Re: Thanks

On 28-Oct-08, at 2:28 PM, Bill Woosley wrote:
> I just wanted to thank you for the use of the validator.

Thanks Bill!

Lots of people put a lot of energy in making this tool (and other  
validators) and such nice feedback does feel good.

--

-- 
olivier

Re: Local installation does not find all erros

Hi Amir,

On 28-Oct-08, at 8:54 PM, Amir Mohammadkhani wrote:
> first off, let me say thanks for this great program. I've been using  
> a local installation of the validator for over 2 years now.

Cool! Always nice to hear from people who installed the tool locally.

> I noticed something strange last week after using the official  
> validator (local one would timeout). I would give me errors where  
> the local one wouldnt.
> So I proceeded to update the validator and made sure I have openSP  
> 1.5.2 as well. I've first updated CPAN and then installed the  
> validator bundle with it.
> Checked every step of the installation process again and again.
>
> It works fine, it does show some errors but does ignore others. For  
> one of my sites (http://www.tarifchecks.de/) the local version says  
> its Valid XHTML
> but when using validator.w3.org I get the following errors:
>
> Line 66, Column 25: there is no attribute "alt".
> Line 67, Column 253: there is no attribute "border".
> Line 80, Column 113: there is no attribute "target".
> Line 118, Column 70: required attribute "alt" not specified.
>
> http://validator.w3.org/check?uri=http%3A%2F%2Fwww.tarifchecks.de&debug=1

This is strange indeed, I don't think I've seen this problem before,  

Re: Centos 4 install for 0.8.3 validator

Hello Andrei,

On 30-Oct-08, at 6:52 AM, Andrei Doicin wrote:
> I am having a hard time installing the 0.8.3 validator on a 64 bit  
> (x86_64) Centos 4 machine.The chain of dependencies has been extreme  
> to say the least.

Sorry to hear that. The validator does depend on a number of libraries  
and tools, and that can sometimes be a pain to install. Would you have  
any suggestions to improve the istallation manual?

> It seems that the 2 most difficult items, at the end of the day, are  
> HTML-Tidy, and the SGML-Parser-OpenSP. Is this a usual thing?

These two should actually not be too hard to install, provided you use  
the CPAN tool which comes with perl, like:
perl -MCPAN -e 'install HTML::Tidy'
and
perl -MCPAN -e 'install SGML::Parser::OpenSP'

> Pls get me onto this mailing list so I can search the archives or  
> get some ideas.

http://lists.w3.org/Archives/Public/www-validator/ has links to  
subscribe to the list. But you can also search the archives directly  
there, even if not subscribed yet.

regards,
--

-- 

RE: Centos 4 install for 0.8.3 validator

Hi

Thanks for your reply. I've managed to get to the end of it in the
meantime, so we have a working markup validator.

I'll try and give you some useful feedback. What happened is that,
rightly or wrongly, I chased dozens upon dozens of dependencies like
never before ("dependency hell", some people call it), that is to say
more binary RPMs, source RPMs, and actual source compilations than I
could mention, or ever  bothered to list. Bringing things in via CPAN
initially never worked so well (especially SGML::Parser::OpenSP or
HTML::Tidy now what you mention it, except maybe AFTER OpenSP was on),
but it was almost certainly compiling OpenSP from source (which is NOT
to be confused with OpenJade, made by the same people, but NOT a
dependency for W3C-Markup-Validator) that resolved the dependency
problems in the end; that, and even maybe a libosp3 RPM, as a dependency
for that or something else I'm no longer sure.

Otherwise, a very useful addition to your install doc would be to
mention exactly where to enter environmental variables such as
http_proxy (in case you are behind a firewall) - which in fact means you
need to hack the actual  "check" perl code yourself, found in
/usr/local/validator/cgi-bin. Although this may be obvious for some, it
may not be for others, and some people may waste time trying to hack
their apache config or who knows what else instead.

I hope that's useful for you. On a related note, I am having some
problems building my .jar file for the css validator, shall I post to
css-validator <at> w3.org, or to the same list here?

Re: DNS Issues

Re: DNS Issues

On 10-Nov-08, at 2:20 PM, . wrote:

> Here's an example screenshot..
>
> The web server IS up.  It's also ping-able by external sources  
> (friends, free proxy sites, etc).

... but it is refusing connections from 128.30.52.13 (one of the  
current validator server) while accepting requests from 128.30.52.49  
(another validator server). I suspect the issue is on your end. Please  
check with your system administrator for some zealous/broken  
firewalling of that IP or IP range.

Regards,
--

-- 
olivier

Re: DNS Issues

Hello,

On 10-Nov-08, at 2:36 PM, . wrote:

> (I'm the administrator)
>
> Both addresses seem to respond properly:
> 64 bytes from 128.30.52.49: icmp_seq=1 ttl=49 time=31.4 ms
> 64 bytes from 128.30.52.13: icmp_seq=1 ttl=50 time=40.8 ms

The issue happens in the other direction.

from ...49

jessica:~# telnet k1t.net 80
Trying 99.140.214.32...
Connected to k1t.net.
Escape character is '^]'.

from ...13

lovejoy:~# telnet k1t.net 80
Trying 99.140.209.81...
telnet: Unable to connect to remote host: Connection refused

So, my bad, it looks like a DNS issue all right, and an issue with the  
validator server.
I purged the local DNS cache on the latter, it should now work fine

lovejoy:/etc# telnet k1t.net 80
Trying 99.140.214.32...
Connected to k1t.net.
Escape character is '^]'.

HTH,
--

-- 
olivier

Re: Centos 4 install for 0.8.3 validator

On Monday 10 November 2008, Andrei Doicin wrote:

> I'll try and give you some useful feedback. What happened is that,
> rightly or wrongly, I chased dozens upon dozens of dependencies like
> never before ("dependency hell", some people call it), that is to say
> more binary RPMs, source RPMs, and actual source compilations than I
> could mention, or ever  bothered to list.

For CentOS 4, this is probably the case - I'm not aware of any pre-packaged 
versions of the validator or all its dependencies for it.  FWIW, for CentOS 5 
it's probably pretty much the same, but the required rpms that aren't 
available in the CentOS or Fedora EPEL repository for CentOS 5 (fewer than 
for CentOS 4 I suppose) should be pretty much a "rpmbuild --rebuild" away.  
(I doubt they'd rebuild as is for CentOS 4.)

> Otherwise, a very useful addition to your install doc would be to
> mention exactly where to enter environmental variables such as
> http_proxy (in case you are behind a firewall) - which in fact means you
> need to hack the actual  "check" perl code yourself, found in
> /usr/local/validator/cgi-bin.

Actually, that is not needed nor recommended.  The "correct" way to do specify 
proxy as well as some other connectivity related settings is via SetEnv in 
httpd.conf (or PassEnv if the variables are already set in the environment 
where httpd is started).  I added some docs about this in CVS:

http://dev.w3.org/cvsweb/validator/htdocs/docs/install.html.diff?r1=1.37&r2=1.38&f=h
http://dev.w3.org/cvsweb/validator/httpd/conf/httpd.conf.diff?r1=1.40&r2=1.41&f=h

Re: checklink: suppress expected errors to avoid false positive warnings

On Monday 20 October 2008, Michael Ernst wrote:
>
> > I don't like the wildly varying separator characters in option values
> > (->, :, #).  Better would be consistent, and we already have the space
> > char used in --masquerade so I suggest using space for the new options as
> > well.
>
> I think the current separator characters consistent and readable.  For
> instance, if we want to suppress warnings about links to
>
>   http://foo.com/bar.html#baz
>
> then it appears that way in the option rather than as the less readable
>
>   http://foo.com/bar.html baz
>
> Likewise, -> is exactly the character sequence that checklink currently
> uses to print out the directory redirect warning message, so writing it
> that way in the option makes sense.
>
> These intuitive, easy-to-recognize separator characters are consistent with
> the checklink output.  I think that replacing them by spaces would make the
> options more difficult and error-prone to read and write.

Well, I guess we'll just have to disagree on this one, in my opinion using the 
space consistently everywhere for similar option syntaxes is clearly the 
better choice.

Otherwise the latest incarnation of your patch you sent me in private mail 
(I'm not sure if it was ever sent to the list) looks fine.  Caveat: I haven't 
actually tested it, just skimmed the code, so I'm taking your word for that 
it works as intended.  Feel free to commit it, but only after changing the 
different option separators all to spaces (in code and docs); or 
alternatively if the consensus of others on this list and the QA dev tools 
team is clearly in favour of using the ->, # and :, commit as is.  But not 
before people have clearly indicated being in favour of using them instead of 
spaces as the separator.