For the tech-geeks
Yeah, another quiet spell. This time I've been focusing on HTTP and related protocols and technologies in preparation for the next major upgrade to sehellenes.org.
It all started when I began reading some of the W3C TAG's excellent and extensive web design and architecture documents. This crystallized some of the issues I've already been running into in serving content. A couple of weeks later, much documentation has been consumed and many shadowy nooks illuminated. And I think I now have an above-average (though still far from perfect) handle on how to map server data to user representations through a public URL interface.
The problem? The server software. I'd really like to use Apache httpd, as it's easily the most mature server I've come across. The problem with this is that I've tried literally for weeks to finagle apache httpd into actually using the W3C's recommended best practices, and it has stalwartly rebuffed me at every turn.
I've found precisely one way to do it "right" using apache, and that involves writing an apache module (in C) to handle the processing correctly, and the prospect of maintaining that code is daunting enough that I'd really rather find a better solution. I also found that Java and Ruby may already have apache modules that allow W3C-recommended URL architecture, but my distaste for those languages puts them on roughly the same desirability level as maintaining my own apache module. And that level, as it happens, ranks just barely less desirable than implementing my own damned HTTP server.
So that's what I'm doing. I've begun writing my own HTTP server to translate my server-based data through a HTTP-based URL interface into user-friendly representations. I sank some time into learning basic OCaml in the hopes that I could take advantage of that language's many fine features. In the end, though, I decided that Python's strong libraries for XML and XSLT outweighed its disadvantages relative to OCaml. So I've begun writing it in Python, and that's going swimmingly. I hope to have server and site-specific configuration available under the new codebase within a few weeks.
So yeah, I've been a little busy.
Anyway, that background aside, on to my actual motivation for posting today. And it conveniently relates to that recent history. Because today, while investigating a DNS vulnerability at work, I ran across the incredibly intriguing RFC 3467. Its title, Role of the Domain Name System (DNS), does a disservice to its content. For while it does examine the role of DNS in the Internet, it does it specifically with an eye toward contrasting the engineering forces that led to DNS's design and creation decades ago with the forces alive on the Internet today. It describes with great acuity many of the naming issues that have plagued the Internet in recent years, notably including (and here's the tie-in to my recent research) the complications of using of DNS names in HTTP URLs. The document was honestly such a brain-opener for me that I needed to post about it before I forgot and lost the details.
That said, despite the issues with the use of DNS names in HTTP URLs, I can't justify putting off sehellenes.org development until Internet service names are rearchitected, so the webserver development pushes onward. And speaking of which, I've got a social engagement to attend.
With thanks to those who've read along and apologies to those who tried but fell behind... laters.
(LJ Spellchecker Genius of the Day: OCaml -> Acme)
It all started when I began reading some of the W3C TAG's excellent and extensive web design and architecture documents. This crystallized some of the issues I've already been running into in serving content. A couple of weeks later, much documentation has been consumed and many shadowy nooks illuminated. And I think I now have an above-average (though still far from perfect) handle on how to map server data to user representations through a public URL interface.
The problem? The server software. I'd really like to use Apache httpd, as it's easily the most mature server I've come across. The problem with this is that I've tried literally for weeks to finagle apache httpd into actually using the W3C's recommended best practices, and it has stalwartly rebuffed me at every turn.
I've found precisely one way to do it "right" using apache, and that involves writing an apache module (in C) to handle the processing correctly, and the prospect of maintaining that code is daunting enough that I'd really rather find a better solution. I also found that Java and Ruby may already have apache modules that allow W3C-recommended URL architecture, but my distaste for those languages puts them on roughly the same desirability level as maintaining my own apache module. And that level, as it happens, ranks just barely less desirable than implementing my own damned HTTP server.
So that's what I'm doing. I've begun writing my own HTTP server to translate my server-based data through a HTTP-based URL interface into user-friendly representations. I sank some time into learning basic OCaml in the hopes that I could take advantage of that language's many fine features. In the end, though, I decided that Python's strong libraries for XML and XSLT outweighed its disadvantages relative to OCaml. So I've begun writing it in Python, and that's going swimmingly. I hope to have server and site-specific configuration available under the new codebase within a few weeks.
So yeah, I've been a little busy.
Anyway, that background aside, on to my actual motivation for posting today. And it conveniently relates to that recent history. Because today, while investigating a DNS vulnerability at work, I ran across the incredibly intriguing RFC 3467. Its title, Role of the Domain Name System (DNS), does a disservice to its content. For while it does examine the role of DNS in the Internet, it does it specifically with an eye toward contrasting the engineering forces that led to DNS's design and creation decades ago with the forces alive on the Internet today. It describes with great acuity many of the naming issues that have plagued the Internet in recent years, notably including (and here's the tie-in to my recent research) the complications of using of DNS names in HTTP URLs. The document was honestly such a brain-opener for me that I needed to post about it before I forgot and lost the details.
That said, despite the issues with the use of DNS names in HTTP URLs, I can't justify putting off sehellenes.org development until Internet service names are rearchitected, so the webserver development pushes onward. And speaking of which, I've got a social engagement to attend.
With thanks to those who've read along and apologies to those who tried but fell behind... laters.
(LJ Spellchecker Genius of the Day: OCaml -> Acme)