<rant>

Among meryln's articles is a very good recent one on cookie management. The article lays out a scheme for handling login/logout by "branding" a browser with a random token that is then used on the server side for access user info and state.

To initially brand the browser, the script first verifies that it isn't looping, then generates a cookie, and next redirects to itself to set the cookie by doing

param("_cookiecheck", 1); # prevent infinite loop print redirect (-cookie => $cookie, -uri => self_url());
Pretty straightforward.

So straightforward that I just burned up 3 hours trying to get it working on IIS, including 1 hour of reconfiguring IIS to save additional info in its logs (IIS will save cookies in the logs, if you know how to ask) and carefully comparing what I thought the script should be doing against what I was seeing on the browser and in the logs.

The redirect was working; _cookiecheck=1 was showing up in the URL, but no cookie was set... until after I acknowledged the form that the script later displays to nag the user into enabling cookies. Huh? Where'd the original cookie go?

Inspecting the relevant parts of CGI.pm and CGI::Cookie.pm shed no light, though they suggested a few avenues for debugging, which -- after another hour of head scratching -- all grounded out.

Then it finally flashed on me to use Google. A search for "iis cgi redirect cookie" turned up this Microsoft KB article, originally written in 1977 1997, which admits that

When a CGI application sends a Set-Cookie header with "302 Object Moved" response and Location header, Internet Information Server (IIS) ignores the cookie header.
Further, they note that this errant behavior is in IIS 3.0, 4.0, and 5.0, and they give no indication that they intend to fix it. As a consolation prize, they mention that by naming your CGIs "nph-*" you can use non-parsed headers, and work around the problem that way.

Thank you, Microsoft.

This may also explain why Microsoft is such an abuser of the the 0 second http-equiv refreshes.

</rant>

Replies are listed 'Best First'.
Re: A Rant on IIS Breakage
by busunsl (Vicar) on Apr 27, 2001 at 10:41 UTC
    Going on with the rant :-)

    <rant>

    There is a solution to your problem:

    Drop IIS and use a decent web server like apache!

    This will give you less problems and more security.

    </rant>

      Drop IIS and use a decent web server like apache!

      Already there for much of my personal work. This one was for the day job.

Re: A Rant on IIS Breakage (solution)
by jplindstrom (Monsignor) on Apr 28, 2001 at 03:38 UTC
    Get this! I once wrote a program (to be installed on numerous servers I had no control over) that broke on account of that problem AND this little gem:

    http://support.microsoft.com/support/kb/articles/Q184/3/20.ASP

    Like, Yes, we know it's a standard, but we think it's plain wrong so we don't do it that way over here, mmmkay?

    The good news for you is that your problem is solved if you run the program as a Perl ISAPI instead of as a CGI. It may require IIS 5 to work.

    The Perl ISAPI plugin is distributed with ActivePerl.

    /J

      Thanks. That KB article explains another long-standing puzzle. Grrrrr....

Re: A Rant on IIS Breakage
by merlyn (Sage) on Apr 27, 2001 at 17:14 UTC
    Got a chuckle on this one:
    .... A search for "iis cgi redirect cookie" turned up this Microsoft KB article, originally written 1977, which admits that ....
    So they've known about it since they were a tiny 15-person company on the 14th floor of a building in Bellevue? And they still haven't fixed it? Doh!

    -- Randal L. Schwartz, Perl hacker

      Freudian typo? Might have been. I was pretty much aghast at their "yeah, we're violating the CGI spec. *yawn*" attitude.

      Besides which, in 1977 they weren't even a 3 person company in Albuquerque.

Re: A Rant on IIS Breakage
by little (Curate) on Apr 27, 2001 at 18:42 UTC
    Does your server have the same local time as the computer with the browser?
    A cookie sent to a browser whos local time is in the future from the view of the server is expired upon delivery. If you don't believe, set your computer clock 1 day to the future or just one hour and you can not permanently log on to perlmonks for example.

    Have a nice day
    All decision is left to your taste
      Does your server have the same local time as the computer with the browser? A cookie sent to a browser whos local time is in the future from the view of the server is expired upon delivery.

      That's only a problem if the browser's clock is set far enough into the future to exceed the expire time of the cookie. In this case, both browser and server were running on the same laptop, so clock wasn't an issue.