afongen

In response to my post the other day about detecting wireless devices, a kind “Web Developer Evangelist” from a company called Dokoni writes with a few sample HTTP_USER_AGENT strings:

• UP.Browser/3.1.04-SY03 UP.Link/4.3.2.3
• Nokia6210/1.0 (03.60)
• Motorola VoxGateway/2.0
• Palmscape/PR5 (PalmPilot Pro; I)
• Mozilla/1.22 (compatible; pdQbrowser 1.08; PalmOS 2.0)
• Mozilla/1.0[en]; Go.Web/1.1 (compatible; MSIE 2.0; HandHTTP 1.1; Palm)
• Mozilla/2.0 (compatible; MSIE 3.02; Windows CE; 240×320)

Oy. Somehow I was hoping that this would be easier or that there might be some reasonable standards emerging in UA strings, but it seems not. I can understand why a company would make a go at selling a product that sifts through this morass to do something useful with the information.

Anybody know anything about how to detect a PDA, cell phone, or other WAP/WML-enabled device? I’m looking to serve up WML or a different style sheet but am not sure how to check for these devices. I’ll do some Googlework but thought someone might know offhand. If so, please email me. Thanks.

Update: Hmmm, it looks like you can check HTTP_ACCEPT for text/vnd.wap.wml — the MIME type for WAP/WML. Great, but how about HTTP_USER_AGENT? The Ultimate Browser Sniffer doesn’t really go there.

Not a bad article on Zend on Secure Programming in PHP. Deals with some very commonly overlooked vulnerabilities. The best I’ve seen, though, is still A Study in Scarlet: Exploiting Common Vulnerabilities in PHP Applications.

For the color impaired, like me: Color Schemer.

I’ve just finished the mod_perl Developer’s Cookbook. Excellent. Truly excellent. This is the book that I wish I had when I started into mod_perl. The Eagle Book is essential but was a bit much for me the first time I read through it. Now that I’ve been working with mod_perl awhile, and especially now that some things have been clarified for me by reading the mod_perl Cookbook, I feel that I can tackle the Eagle Book again and get a whole lot more out of it. With all the handy and well-explained examples in the Cookbook, many of which show how to do things I’ve been wondering about for a long time, I feel ready to tackle some of the tougher projects that I’ve let languish. I have so many, many ideas for things that I want to tackle with mod_perl.

What’s so special about mod_perl, you ask? For starters, and I admit that this was what sparked my first interest in it, it embeds a perl interpreter in the Apache server, cutting down on the startup time that causes the bottleneck in a CGI environment. But hey, that’s what mod_php does, so maybe you think that’s nothing special. And although important, it’s hardly what I find most exciting about mod_perl. No, the beauty of mod_perl is that it offers hooks into the Apache API: access to the server’s internal processes. The power and flexibility that this affords the developer makes me giddy. And terrified.

Every now and then I find myself in a discussion about the merits of one web server over another (usually IIS vs. Apache). mod_perl is one of the top reasons that I like to use Apache.

In case you’ve been wondering when to use <abbr> and when to use <acronym>, that message should make it clear. As it turns out, I’ve been misusing <acronym>. Stupid me. It should have been clear, but I was overgeneralizing and using <acronym> for things like SVG. Oh well. Live and learn.

A couple fun things coming up soon:

First, my colleague Sara and I will be providing accessibility training to MnSCU webmasters across the state. This is part of a strong effort being undertaken to highlight the need for accessible web resources, especially important since MnSCU (my employer) is both a higher ed institution and a government agency. It’s also an opportunity for me to completely rewrite our accessibility guidelines, which are based on the just plain sad and often incorrect Minnesota State guidelines. Part of me would just like to point to the W3C Web Accessibility Initiative, but that won’t cut it.

Second, my colleague Matt and I will be presenting a session on XML at the upcoming MnSCU IT conference. Matt is the guy who proved to me that client-side XSLT is workable; until then I’d been myopically convinced that server-side XSLT was the only way to go. Our goal is to demonstrate that XML isn’t just an up-and-coming technology, but that it’s here and can be worked into web sites right now. Matt will show some of the cool ways that he’s been using XML in his site’s back end (as a data store, mostly) and maybe some of his client-side magic. For my part, I’ll show a bit of XML and SOAP at work. Oughta be a party.

I love it. Today I got spam with headers forged to look like it came from the webmaster at afongen.com. Uh, that’s me. I don’t think you’re fooling anyone.

Awww, CmdrTaco proposed today on Slashdot.

13th Parallel: Designing for Standards: Separating structure from style and behaviour.