ISAPI Rewriting, Devices and Korean XML

Taking all my TFTP Provisioning Service stuff at my day job today and providing an HTTPS alternative. Seems that some VOIP devices want to make an HTTPS call for their configuration files.

They expect what the manufacturer programmed them to expect, which in this particular case is what one dood referred to jokingly as "Korean XML" - it has no root element!

That's no big deal, I'll do my stuff and send the device whatever it wants, well-formed or not. The big problem is the device is only smart enough to ask for:


Ok, now how the hell am I gonna map that to my:


The answer? ISAPI_Rewrite from Helicon. They have a freeware version, and it handles very nice REGEX URL Rewrites at the IIS level (e.g., way before you ever get to ASP.NET) - which was exactly what I needed.

The Rules file for this particular one is elegantly simple:


RewriteRule /myweb/(.*)\.xml /myweb/default.aspx\?id=$1 [I]

Boom! Every request for an XML File in that folder comes into my ASP.NET page, with the DEVICEKEY info right on the querystring where I want it, and the device could care less! The device is asking for a physical file; I am assembling that file's contents via a whole bunch of database and rules logic, and putting it on to the Response Ouput stream, and the device is as happy as a Korean Ch'usok dancer.



Google Talk, XMPP, standards - Taking it all "Up a Notch"?

Guess what: Google is talking. And, they are saying Client Choice, Service Choice, Platform Choice.

Any client that supports Jabber/XMPP can connect to the Google Talk service. There's service interoperability, and there's platform interoperability. This is about real standards - (not like "Ajax" which is about marketing hype).

You can read up on Google's "Talk Posture" here. Now the Talk service may not make Google any real money. It's really hard to measure.

But, you know what? Google has clout, and I bet it certainly just woke up the worldwide developer community. Microsoft, are you "listening"?

Allow me to explain: The lines are drawn between two protocols working their way through the IETF standards body: the SIP (Session Initiation Protocol)-based SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) and the open-source, XML-based protocol XMPP ( eXtensible Messaging and Presence Protocol). Vendors are hoping to choose the correct side of the market's eventual shakeout. IBM and Microsoft are in the SIP/SIMPLE camp. Google is in the XMPP camp.

Because the SIMPLE protocol is still incomplete, IBM's and Microsoft's implementations have required the addition of proprietary extensions to make their offerings work. XMPP's proponents contend it is more mature than SIMPLE and better suited to handle IM and presence awareness.

XMPP was built from the ground up as a an open-source signaling protocol for messaging, tapping an XML streaming technology that is optimized for real-time data exchange, according to the Jabber Software Foundation.

Some experts feel at this point that In the end, the industry will most likely rally behind a standard that blends both protocols, likely be a hybrid of XMPP, propriety ideas, and some generic work in IETF around SIP and SIMPLE.

This all sounds familiar, doesn't it? We had this with SOAP, with XSLT, CSS-2, and several other "growing pains" standards.

Bottom line? Standards are good for everybody - the big folks, and the little folks too. And, they come a lot faster when people stop screaming "Me, Me!" and start talking to each other.

But in the VOIP business , the real toll collector's position is still going to be held by the people who control the termination of all these VOIP calls into the PSTN at the local Telco's C.O. and it comes out of the copper wire in your house and makes your old fashioned phone ring. Trust me.


Don't you just love the funny graphics software companies use to promote their releases? Here's one with a custom caption I've added that seems to better describe what's really happening!


The AJAX Dilemma: Is Another Acronym Needed?

One of my recent articles on eggheadcafe.com got some comments. Some were interesting, some were your typical "comment spam", and a couple, while seemingly authoritative, (including one from an author who has a new book on the subject), were actually erroneous.

Adaptive Path's guru Garrett's canonical example of his "AJAX" acronym is Google Suggest:

"Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what's possible on the Web."

Immediately thereafter Garrett decrees the "rules" of his premise with these bullet points:

"Ajax isn't a technology. Its really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:
  • standards-based presentation using XHTML and CSS;

  • dynamic display and interaction using the

  • Document Object Model;

  • data interchange and manipulation using XML and XSLT;

  • asynchronous data retrieval using XMLHttpRequest;

  • and JavaScript binding everything together."

  • The problem is that neither does Google Suggest use XML nor does it use XHTML, or CSS! In fact it doesn't even necessarily use XMLHTTPRequest: if your browser doesn't support it, it degrades gracefully to the hidden IFRAME technique made popular by Brent Ashley back in 2000 with his "JSRS" Remote Scripting implementation.

    Here's the crux of this Ajax issue as I see it: Remote Scripting is the basic technique that has been around since 1998, which I define as that of making an out of band request (either synchronous or asynchronous) to a web resource and bringing back the information to be displayed or inserted into an existing web page with no form post or page reloading. If you want to add XML, XHTML, CSS, XSLT, that's your business, and goody for you. You still did "Remote Scripting". XML and XSLT, whiile not often used for this, have to do with the transport layer and transformation of same to the UI layer; they're standards that are used by thousands of developers either with or without the use of Remote Scripting. CSS and XHTML are standards that have to do with the UI layer, and once again, widely used by web developers without Remote Scripting. And let's get one final item straight: the XMLHttpRequest object is not a W3C standard.

    Now Garrett comes along and defines a new technology, specifying Google Suggest as a generally accepted example of it, and it doesn't even follow his own rules! No wonder AJAX is so confusing to the general development community! Nobody can even agree on WHAT THE HELL IT IS! Oh, sure, plenty of people (as the bullets above show) are happy to TELL YOU what it is, but that is virtually meaningless unless a whole bunch of people agree on the rules! SOAP wasn't "SOAP" until a lot of people who had been working very hard on it for several years finally agreed it was done, and the standard was formalized. Now this chap Garrett comes along and sees a marketing opportunity, puts some cool pieces together and gives them a snazzy name, and I'm being told by book authors that it's all about "Web Standards". Bullshit! Almost all the implementations of Remote Scripting techniques that call themselves "Ajax" that I've seen so far could care less about Web Standards! Instead, they're about translating the remote scripting calls using JSON or prototype Javascript "quasi objects" that will marshal the data back into the page correctly. Many of them completely ignore the state context of the page proper and seem to be more concerned with making an out of band call to some external URL or HttpHandler that has no way of acessing the server-side page context, and then just returning some data.

    Hey, of course I think observing web standards is important! But the standards were already there to observe! Coining a new buzzword to cover a very old technique which may or (as is often the case) may not include various other techniques and standards does very little to legitimize the concept. So if i wrote a web page that uses some Remote Scripting to return some data but I don't use XML with it, is this now "NOT AJAX", because I didn't observe all of Garrett's "rules" (which by his own example he doesn't even observe himself!)? You want to pontificate about "AJAX" as being about web standards? Submit it to W3C and ask for a recommendation and get it ratified. Then you can talk about standards.

    The whole thing, to me, is so childish and asinine as to be almost laughable! I tell you what -- when the W3C or OASIS gives me a spec that says what AJAX is, that's the day I'll start using the term. Don't hold your breath. Remote Scripting with Web standards compliant XHTML, CSS, XSLT, etc -- is simply Remote Scripting with XHTML, CSS, and XSLT. AJAX? Its a foaming cleaner put out by Colgate-Palmolive.


    Blogger offers Word Plug-In, and HTTP KeepAlive

    Blogger has a free downloadable Word plug-in that allows you to make blog posts from within MS Word. It doesn't support images though, so if you want to upload a picture of your newest product (as seen at left) you'll need to do that separately.

    Oh, well...

    We had an interesting post on our Eggheadcafe.com forums today:

    "What is the best way to establish an http protocol communication link to POST data using a persistent connection ? How can i verify that a connection is made ? what classes will i be using in .NET, what is the easiest way to go about it ? the protocol will be http1.1 Thanks"


    HTTP is not like TCP Sockets
    so when you make an HTTP Request Whether the request method is either GET or POST, the only way you can be sure that you have made a connection is to look at the RESPONSE. The term "Persistent Connection" when referring to the HTTP Protocol is somewhat misleading because it can lead folks to believe they have the equivalent of an open TCP Socket connection, which is not true. Http operates on what is called a request-response paradigm. This means that a client generates a request for information, and passes it to the server, which answers it. In the original implementation of HTTP, each request created a new socket connection to the server, sent the request, then read from that connection to get the response. Under HTTP 1.1 the Connection: Keep-Alive header no longer has any meaning. Also, an optional Keep-Alive: header is described, but is so underspecified as to be meaningless. The bottom line is that HTTP is a stateless protocol - this means that every request is independent of every other. Keep alive doesn’t change that. Additionally, there is no guarantee that the client or the server will keep the connection open. Even in 1.1, all that is promised is that you will probably get a notice that the connection is being closed. So keepalive is something you should not write your application to rely upon.


    Is it about Cindy Sheehan?

    Cindy Sheehan isn't responsible for her son's death, nor is the President or anyone who supports the war.

    Some terrorist in Iraq is responsible. Had her son not gone to Iraq he would probably be with us today, but it was his decision to go there.

    He re-enlisted after the war had begun knowing full well that he'd likely be headed to Iraq. He was an adult and made a decision. His decision was to continue his service in the military. He clearly believed in the mission, even though his mother does not.

    When President Bush returns to the White House after his working vacation at his Crawford ranch, Cindy Sheehan will most likely go home and shut up. I'm really sorry she has lost a son. War is not fun. People die.

    But -- here, the left wing anti-war establishment, desperately looking for poster children, has made a bad pick for a poster Mom. Harry Belafonte probably would be better. At the least, he can sing pretty well, and his face is more familiar.

    This is what the Sheehan family has to say:

    "The Sheehan Family lost our beloved Casey in the Iraq War and we have been silently, respectfully grieving. We do not agree with the political motivations and publicity tactics of Cindy Sheehan. She now appears to be promoting her own personal agenda and notoriety at the the expense of her son's good name and reputation. The rest of the Sheehan Family supports the troops, our country, and our President, silently, with prayer and respect.


    Casey Sheehan's grandparents, aunts, uncles and numerous cousins."

    How 'bout it, Mrs. Sheehan? President Bush has already met with you personally, do you remember? Do you really enjoy being exploited like this as a mere "plaything du jour" of the anti-war left? When I was younger, I had a friend who died in Vietnam. I managed to stay out of the Service - I even peed on the wall of the Pentagon once. But I like to think that I grew up, too.


    IISState- troubleshooting IIS 6.0 issues And European English

    If you have ever had process recycling issues under IIS 6.0, often your best bet is to use IISState to take some "dumps" and examine them. There is a whole newsgroup devoted to this issue.

    There is also a newer version of IISState than that which ships with the IIS Resource kit, and you can find out about it on this excellent site here.

    Another issue that goes hand-in-hand is the monitoring of IIS App Pool events. By default, extensive logging is turned off. However you can turn it on with:

    csript adsutil.vbs set w3svc/AppPools/<AppPoolName>/<AppPoolEventToTurnOn> true

    Here is a link to the KB article that describes all this in more detail:


    On a lighter note, Milan Negovan has a funny piece he's quoted about the changing standards of European English for the EU.

    PayPal Scams and Bulgarian "New York Style" Bagel Crisps

    I get these (the PayPal scams, not the Bagel Crisps) relatively frequently (as most of us do) and I've developed a quick and very efficient technique to help thwart these bastards. which I'd like to share:

    1) First, understand how to identify a Paypal scam email. You can do that by visiting here. The most important thing to understand is that you can make a hyperlink say anything you want. It's the underlying URL that's important. In most email clients, if you mouse over the link, you'l get a tooltip that shows you the real link URL. If it is anything else except "https://www.paypal.com/cgi-bin/webscr/?cmd=_login-run ", then you can BET its a scam.

    2) Do a whois lookup on the domain of the target url. This usually only takes a minute. Now you know who the domain is registered to. This is usually, but not always, the perpetrator. In many cases, you can actually get their name, address, and contact email!

    3) At this point, what I usually do is trace back to the nameservers or do a Tracert (DOS COMMAND: Tracert www.badguy.com ) to find out where its landing. The last entry in the traceroute list before the actual target IP Is usually the domain of the hosting company.

    4) Then, i forward the spam email to abuse@thehostingcompany.com with a note that they are hosting a Paypal scammer and they better FIX IT. Usually, if they are reputable, they will put the guy out of business within FIVE MINUTES. I just did one to somebody from menage-paypal.com that turned out to be hosted in Poland, and I got a thank you reply within minutes.

    5) you can of course forward the errant email (preferably with the full email headers) to spoof@paypal.com. However, they are pretty overloaded, so a little vigilante-ism as above can certainly help!

    If more people do what I describe above, or similar actions, we can all help to make it very unprofitable for the spammers to even try anymore.

    The moral of the story is:

    Everything is not always what it seems, so be aware. There really are people out there who want to hurt you, and they DO NOT CARE! So, instead of being fearful, what you need to do is take steps to PROTECT YOUR ASS. I just looked at the side of my bag of "New York Style" Bagel Crisps. They're made in BULGARIA. That's doesn't "rip me off", but it's an example. You gotta understand something: These spammers and scammers are just like terrorists. You DON'T NEGOTIATE with these manaics. You dont "hope" that they will go away. What you do is you GO AFTER THEM, wherever they are, and YOU PUT THEM OUT OF BUSINESS. Period!



    Scott Hanselman blogs about a GotDotNet user sample that allows you to strip document declaration


    However, one of the comments to the posted solution comes up with what may be an even more elegant solution that does not rely on reflection:

    "Rather than use reflection and change the internal state of the writer, you could also write something to the XmlTextWriter instance. "

    Here is s "short but complete" (a la Jon Skeet) example I whipped up:

    using System;
    using System.Xml;
    using System.Xml.Serialization ;
    using System.IO;
    namespace XmlserializerFaker
    public class SerializationHelper
    public static string ToXml( Object o )
    XmlSerializer serializer =
    new XmlSerializer( o.GetType() );
    StringWriter stringWriter =
    new StringWriter();
    // Create an instance of an xml text writer, with no formatting.
    // Then write something (actually nothing) to the writer
    // in order to set the internal state to something other than the
    // start state, which omits the xml declaration.
    XmlTextWriter xmlWriter = new XmlTextWriter( stringWriter );
    xmlWriter.Formatting = Formatting.None;
    xmlWriter.WriteRaw( "" );
    // Faking the existence of custom namespaces has a nice side effect
    // of leaving namespaces out entirely.
    XmlSerializerNamespaces faker = new XmlSerializerNamespaces();
    faker.Add( "",
    null );
    serializer.Serialize( xmlWriter, o, faker );
    return stringWriter.ToString();
    public class EngineState
    private string _name;
    public string Name
    get{ return _name;}
    public EngineState(){}
    public EngineState(string name)

    this.Name =name;
    class ShowMe
    static void Main(string[] args)
    EngineState st =
    new EngineState("Ted");
    string x= SerializationHelper.ToXml(st);
    Console.WriteLine (x);

    This kind of trick can be especially useful to serialize a class that represents a state or configuration, and just save it as more or less a "config" file.


    Blogher? Sorry, I don't get it.

    I've been reading some posts about Blogher recently and frankly, I just don't get why women need to have a "women's blogger conference".

    I read all kinds of blogs, I'm interested in the content, and I could care less whether its a man, a woman, a transsexual, or a dog doing the blogging, as long as the content is valuable to me.

    So, somebody please explain this to me. Sounds kinda like Women's Lib "Déjà Vu all over again" to me.