Tech Off Thread

6 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Bug in IIS? Or HTTP + CGI?

Back to Forum: Tech Off
  • User profile image
    Maurits

    David Wang made a very informative post on Thursday regarding a feature added to IIS 6.

    The feature adds support for ISAPI programs, ASP, and ASP.Net to be able to access headers that contain an underscore (like SM_User:)

    The CGI spec says that most headers are to be added to the "environment" of a CGI program, with the HTTP_ prefix prefixed, with "-" replaced by "_" throughout, and with lowercase letters uppercased.

    And sure enough, an ASP script can call Request.ServerVariables("HTTP_ACCEPT_ENCODING") and get the value of the Accept-Encoding: header.

    Reportedly (I have not yet confirmed this, though I plan to:)
    ASP can not call Request.ServerVariables("HTTP_SM_USER") and get the value of the SM_User: header (note the underscore in the header name.)

    David considers this a flaw in the spec.  As I noted in the comments to the post, I disagree.  It seems to me to be simply a bug in IIS.  IIS is, in my view, not correctly implementing the CGI spec.  This is probably due to a misreading of the spec, rather than intentional sabotage.

    What do you think?  Is the bug in IIS, or in the spec?

    EDIT: confirmed.  Repro and analysis posted.

  • User profile image
    Cannot​Resolve​Symbol

    Maurits wrote:
    David Wang made a very informative post on Thursday regarding a feature added to IIS 6.

    The feature adds support for ISAPI programs, ASP, and ASP.Net to be able to access headers that contain an underscore (like SM_User:)

    The CGI spec says that most headers are to be added to the "environment" of a CGI program, with the HTTP_ prefix prefixed, with "-" replaced by "_" throughout, and with lowercase letters uppercased.

    And sure enough, an ASP script can call Request.ServerVariables("HTTP_ACCEPT_ENCODING") and get the value of the Accept-Encoding: header.

    Reportedly (I have not yet confirmed this, though I plan to:)
    ASP can not call Request.ServerVariables("HTTP_SM_USER") and get the value of the SM_User: header (note the underscore in the header name.)

    David considers this a flaw in the spec.  As I noted in the comments to the post, I disagree.  It seems to me to be simply a bug in IIS.  IIS is, in my view, not correctly implementing the CGI spec.  This is probably due to a misreading of the spec, rather than intentional sabotage.

    What do you think?  Is the bug in IIS, or in the spec?
    \

    So, if you're adding the headers to the environment of the program, you'll get all your headers, with - replaced with _.  You should be able to access headers with _, because _ is not replaced with anything (Unless, for some reason, you got a header SM-User and SM_User).

    IIS is not implementing Request.ServerVariables correctly.  It is replacing _ in the requested environment variable with - and getting that header directly.  It can't do that, because there may be a case where there was an underscore there to start with.  The only way to work around this would be to change all the headers into the form CGI uses ahead of time and request from this.

  • User profile image
    Maurits

    Oh good, this is a known issue.  See KB 294217

  • User profile image
    W3bbo

    Maurits wrote:
    ... or maybe not... David has disavowed the KB article.


    Funny how IIS6.0 isn't listed under the "Products Affected" list.

  • User profile image
    Maurits
  • User profile image
    Maurits

    FWIW, Perl agrees with me.  From the CGI.pm manpage:

    Lincoln D. Stein wrote:

    Capitalization and the use of hyphens versus underscores are not significant.

    For example, all three of these examples are equivalent:

       $requested_language = http('Accept-language');
    $requested_language = http('Accept_language');
    $requested_language = http('HTTP_ACCEPT_LANGUAGE');

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.