On IIS Team Blogging, Part 2

Back in this blog entry, I mused about how nice it would be to have more bloggers from the IIS product team. One thing is for certain - the IIS team traditionally has never dialed up the volume when it comes to evangelizing what we are doing and its importance as the foundation of the entire Microsoft web platform. We tend to be treated like a cog that has to keep turning and no one notices it until it stops turning. 😛 Yes, I know that Atlas is sexy and so is ASP.Net, but they go no where without some basic support from IIS and Windows.

Anyways, I got wind of some new IIS Bloggers coming... people who actually have review commitments to blog. Some have queried me quite a bit about how to approach blogging, so of course I gave them the summary of what I have concluded. I told them:

  1. Have a target audience in mind and write to it. Like a TV channel, do not try to appeal to everyone because you end up appealing to no one.
  2. Have a "point" and stick to it. Like a TV show, people naturally gravitate towards the type of material they like. Your audience will gather, so do not change your point to chase after the audience. You have a target audience in mind, remember?
  3. Blog often. If the content is not fresh or active, neither is your audience. This is not MSDN.

Of course, lately I have been pushing at the boundaries of the second "point" quite a bit by trying a variety of blog topics (like the Office Move, Lumiere, Blog Upgrade)... which bring in more of the human factors but still remain within myself and audience. As I see it, this is just an extension of an original goal... disseminating information about IIS as well as the people/process/circumstances around building IIS can be interesting. Hey, it certainly lightens things up a bit more for me. 🙂 You can tell me whether you want more or less of that, of course.

Hopefully in the near future, these new IIS bloggers will start and tell me about it so that I can link them in... and give them a good greeting. 🙂 Hehe... I'll just put them on the spot by giving names, job role, and short personal blurb:

  • Bill Staples, product unit manager for IIS. He's charged with shipping IIS7, amongst other things.
  • Dave Cox, test lead. He owns IIS7 Configuration, Stress, and Administration (excluding UI). He also has a lot of context on WebDAV and IIS6/UNC having owned those areas in IIS6. 
  • Oscar Omar Garza Santos, program manager. He owns IIS7 Configuration, Administration, and other loose ends. He can explain.

Unfortunately, I still cannot get a IIS developer to start a blog. They have quite the story to tell if they would only write it all down. I have some candidates in mind, but I won't bug them now; they are already crazy with developing features and fixing bugs.


Comments (14)

  1. Maurits says:

    Could you ask one of those guys about IIS accepting non-standard

    Authorization: Digest … qop="auth", algorithm="MD5" …

    headers, but refusing standard

    Authorization: Digest … qop=auth, algorithm=MD5 …

    headers? See RFC 2617.  This breaks Digest Authentication for non-IE clients.

  2. Maurits says:

    For an example of how it breaks Firefox, see Firefox bug 330702:


  3. David.Wang says:

    Maurits – The developer of Digest implementation in IIS6 told me that IIS6 and later supports both qop=auth and qop="auth" from the client, so this is a non-issue going forward regardless of what the client chooses to do.

    As for IIS5 – any change there requires opening a PSS support case and having the change accepted.


  4. Maurits says:

    OK great, thanks

  5. Maurits says:

    Hmmm… it is unfortunate, then, that IIS 5 is so much more prevalent than IIS 6[1].  Any possibility of releasing a patch for IIS 5?

    1: http://www.port80software.com/surveys/top1000webservers/ for example

  6. Maurits says:

    Er, never mind, that surveys rather old.  Looking for more recent data…

  7. Maurits says:

    Just visited the support center to open a PSS case…

    Oy.  I don’t want to pay for the privilege of filing a bug.  $99 for email support?  To retrofit an existing IIS 6 patch to IIS 5??

  8. David.Wang says:

    Maurits – No, it is not "paying for the privilege of filing a bug".

    Filing bugs are "free". You get charged up front and then get refunded at the end of the process. We have to do this to prevents frivolous abuse of support, where people make Microsoft frontline support of *all* products that run on Windows because "Windows doesn’t run my program".

    In other words, the initial charge weeds out:

    1. the users with illegitimate issues

    2. the users that really don’t want the issue resolved

    If you have a legitimate issue and bug to report and you want it resolved, you will be ok with the initial charge and be happy to see that it is later refunded to you. It pays to be persistent…

    Now, your notion of how software maintenance works… is interesting.

    IIS6 is architecturally different than IIS5, so it is not a simple matter of "retrofit an existing IIS6 patch to IIS5". It’s like if you wanted to retrofit an Apache 2.x fix onto arbitrary Apache 1.x branch; not many people would do that for FREE AND be responsible to support the change…

    Also, you have to consider costs of regression testing, business opportunity cost, difficulty/riskiness of the change, etc. If the bug costs too much to fix and the rewards are little… why fix it?

    In other words, software is never bug free, but not all bugs are worth fixing. I know from an end-user’s perspective, they are surprised about this — shouldn’t all bugs be fixed ? Nope… this is the reality of shipping and maintaining software. This process does not change between Open Source and Closed Source; only difference is responsibility, support, and liability.


  9. Maurits says:

    OK, I’ll see what I can do.

  10. Maurits says:

    Management was very willing to put up the $99 deposit.

    Support Request Number – SRZ060321001678

  11. Maurits says:

    The case engineer confirmed that this is a bug in IIS 5.  He recommended that we either:

    * migrate to IIS 6


    * require visitors to use Internet Explorer for Digest-protected resources

    The $99 was refunded and the case closed.

  12. Maurits says:

    In fairness, he also suggested that the problem could be fixed by writing an ISAPI to replace qop=auth with qop="auth" on incoming requests.

  13. Maurits says:

    > writing an ISAPI to replace qop=auth with qop="auth"

    I’ve thrown one together:


    Confession: I was weak and used the MFC ISAPI template. 🙁 But I am reading this excellent post


    and hope to eliminate the MFC-ness soon.

  14. Maurits says:

    Er, wrong link.  This is the correct link:


Skip to main content