Archive for November, 2007

XHTML compliance, .NET2 and validator.w3c.org

Friday, November 9th, 2007

Something to watch out for …

We had a minor “hiccup” on www.immediacy.net yesterday when we noticed that validator.w3c.org was reporting 2 XHTML 1.0 strict validation errors on the home page. We take XHTML compliance pretty seriously as it is one of the selling points of our content management system.

The built in Immediacy XHTML checker wasn’t reporting any problems and a visual inspection of the XHTML source code implied that validator.w3c.org was actually mistaken in reporting any errors.

We’ve recently switched the Immediacy.net site to running in .NET2 and I suspected this may be the cause of the problem.

A bit of investigation revealed that when validator.w3c.org requests pages from a site, it does so with a user_agent value of “W3C_Validator”.

.NET has the “ability” to automatically recognise what it considers to be “downlevel” browsers and re-render certain HTML controls differently to match the capabilities of the browser. The theory is that .NET can automatically downgrade a website to automatically support devices such as phones and pdas, however in practice I’m not sure how well this works.

.NET was determining that “W3C_Validator” was a downlevel browser and rendering different HTML to the validator than to human visitors of the site.

The solution is relatively straightforward. Simply paste the following configuation code into the “browsercaps” section of the web.config on your website. This will tell .NET to treat W3C_Validator as if it were a Mozilla browser.

<!– Gets .NET to treat validator.w3c.com as if it were Mozilla. Otherwise it tends to render invalid XHTML !!–>
<case match=”^W3C_Validator/”>
browser=Mozilla
frames=true
tables=true
cookies=true
javascript=true
javaapplets=true
ecmascriptversion=1.5
w3cdomversion=1.0
css1=true
css2=true
xml=true
tagwriter=System.Web.UI.HtmlTextWriter
version=6.0
majorversion=6
minorversion=0
</case>
<!– end W3C_Validator–>

XHTML 1.0 strict compliance restored

Reverse DNS Lookup from MS SQL Server

Tuesday, November 6th, 2007

The following SQL script demonstrates how to perform multiple reverse DNS lookups from MS SQL Server.

The script uses the xp_cmdshell stored procedure to execute the nslookup DOS command. The output from this command is then imported into a database table.

You will need to enable xp_cmdshell in the “Surface Area Configuration Tool” on your SQL Server. This does have security implications when running in a high security production environment, so you may prefer to run this script in a non-production environment.

This particular script updates a table called ip_address_data for entries where the column arp_domain is currently null. The script also logs a date when the reverse DNS lookup was done so that you can periodically refresh the domains.

Minor caution: it takes a relatively long time in database query terms (about 1 or 2 seconds) to perform each reverse DNS lookup, you need to factor this is into any processing you do with this script.

declare @ip_address varchar(16)
declare @cmd varchar(100)

declare curs cursor LOCAL READ_ONLY
for select ip_address from ip_address_data where arp_domain is null
open curs

create table #output(line nvarchar(100))

while 1=1
begin
fetch next from curs into @ip_address
if @@fetch_status != 0 break

set @cmd = ‘nslookup ‘+@ip_address

insert into #output
execute xp_cmdshell @cmd

update ip_address_data set
arp_domain = (select substring(line,10,99) from #output where line like ‘Name%’),
last_cached = getdate()
where ip_address = @ip_address

delete #output

end

drop table #output
close curs
deallocate curs