Ovid has asked for the wisdom of the Perl Monks concerning the following question:

Here's a very reduced test case of my problem code code: 
#!C:\perl\bin\perl.exe
use CGI;
my $cgi = CGI->new;
my @cookieOut;
push @cookieOut, ($cgi->cookie( -name    => 'id',
                                -value   => "something",
                                -expires => '+7d',
                                -path    => '/'));

print $cgi->redirect( -cookie   => \@cookieOut,
                      -location => 'productCategory.cgi' );

[download]
Apache seems to handle this just fine. Unfortunately, here's what I'm getting from IIS 4.0: 
HTTP/0.9 200 OK
Client-Date: Fri, 22 Dec 2000 21:02:08 GMT
Client-Peer: 192.168.1.65:80

Status: 302 Moved
Set-Cookie: id=something; path=/; expires=Fri, 29-Dec-2000 21:59:38 GM
+T
Date: Fri, 22 Dec 2000 21:59:38 GMT
Location: productCategory.cgi

[download]
Notice that the Client-Peer line has an extra newline, effectively ending the headers and killing any chance of a redirect. Also, I notice that it says HTTP/0.9. If I add print $cgi->header; before the redirect (I was just testing, I know it breaks it), all of a sudden, IIS reports HTTP/1.0 -- still not to HTTP/1.1, but I have no frickin' idea what's up with that.

I need to know what's up with the extra newline in that header. Again, it works fine for Apache. Is there something in my code I can change to get this to work with IIS, or is this just a server issue?

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Replies are listed 'Best First'.
Re: IIS and Apache
by chromatic (Archbishop) on Dec 23, 2000 at 05:13 UTC
    I think merlyn is on the right track. Try something like this: 
    print $query->redirect( -cookie => \@cookieOut,
    -location => 'productCategory.cgi',
    -nph => 1 );

    [download]
    You might also try 'uri' instead of 'location', but I doubt that is the problem.
[reply]
[d/l]
Re: IIS and Apache
by merlyn (Sage) on Dec 23, 2000 at 04:59 UTC
    I may be mismembering, but if I recall, IIS wants NPH-style headers all the time. Maybe header() gets it right (autodetecting IIS and dumping NPH mode), but redirect() messes up.
    time passes...
    Hmm. Nope... redirect calls header, according to the source. Scratch that idea. Do you have a fairly recent CGI.pm?

    -- Randal L. Schwartz, Perl hacker

[reply]
[d/l]
[select]
Re: IIS and Apache
by extremely (Priest) on Dec 23, 2000 at 16:03 UTC
    Run this under IIS and see what happens: 
    #!C:\perl\bin\perl.exe
print <<EEK;
Status: 302 Moved
Set-Cookie: id=something; path=/; expires=Fri, 29-Dec-2000 21:59:38 GM
+T
Date: Fri, 22 Dec 2000 21:59:38 GMT
Location: productCategory.cgi

EEK

    [download]

    and see what happens. That should boil down that it is IIS, now try changing the order of the headers, specifically, move Status: to last or just before Location:

    I vaguely remember this sort of thing with IIS. I recall it being sensitve to header order. Maybe I'm just insane tho. =)

    --
    $you = new YOU;
    honk() if $you->love(perl)

[reply]
[d/l]
(Ovid - response to IIS responses) Re: IIS and Apache
by Ovid (Cardinal) on Dec 24, 2000 at 00:00 UTC
    Responses:
    • merlyn: I've installed CGI.pm 2.74 on the box in case that was the problem. Didn't help. I suggested using NPH to deal with this since it looks like a server issue, but that idea was vetoed.

    • chromatic: I tried uri instead of location and that made it worse! The header reported Location: uri Ack! Of course, that was before I upgraded to 2.74, so I'll try it again after Xmas.

    • extremely: I like that idea! I'll give that a shot, too.
    IIS: whudda piece of work. Can anyone think of any valid reason why it should report different versions of the HTTP protocol? Not to mention its apparent munging of headers -- though the jury's still out on that.

    Amusingly, when I upgraded CGI.pm, I noticed CGI::Utils. Hmm, what's that?

    I opened it up and noticed, amongst other things, that it includes EBCDIC support. Immediately, my eyes rolled into the back of my head and I started foaming at the mouth. Fortunately, the IS director rushed over and whispered "no more mainframes" over and over until the convulsions subsided. Whew! That was scary.

    Cheers,
    Ovid

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[reply]
      Oh, don't blame IIS on the headers thing, Apache has to do the same thing... 
      <IfModule mod_setenvif.c>
    # The following directives modify normal HTTP response behavior.
    # The first directive disables keepalive for Netscape 2.x and brow
+sers that
    # spoof it. There are known problems with these browser implementa
+tions.
    # The second directive is for Microsoft Internet Explorer 4.0b2
    # which has a broken HTTP/1.1 implementation and does not properly
    # support keepalive when it is used on 301 or 302 (redirect) respo
+nses.
    #
    BrowserMatch "Mozilla/2" nokeepalive
    BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-respon
+se-1.0

    #
    # The following directive disables HTTP/1.1 responses to browsers 
+which
    # are in violation of the HTTP/1.0 spec by not being able to grok 
+a
    # basic 1.1 response.
    #
    BrowserMatch "RealPlayer 4\.0" force-response-1.0
    BrowserMatch "Java/1\.0" force-response-1.0
    BrowserMatch "JDK/1\.0" force-response-1.0
</IfModule>

      [download]

      I've got a lot of gripes with IIS but broken clients just something you have to deal with.

      In fact, that brings up another thought. Have you tried sending different User Agent strings to IIS with that request? That may be part of the problem too. Yah never know when you can't muck with the innards.

      --
      $you = new YOU;
      honk() if $you->love(perl)

[reply]
[d/l]
      That IIS is reporting HTTP/1.0 at one point and 1.1 at another makes me think that it's possible that two instances of IIS are running in the background. It may even be possible that one of these instances of IIS is 3.0! Then again, I may be horribly off base--but in any case you might try completely uninstalling and reinstalling IIS 4.0.

      Good luck. =)

[reply]
Re: IIS and Apache
by dws (Chancellor) on Dec 24, 2000 at 04:03 UTC
    I banged my head into a wall on this one with IIS4.0 a year ago, and finally fell back on using a 0 second refresh. 
    <meta http-equiv=refresh  content="0;url=http://www.example.com/overhere.html">
    Not ideal, but it gets the job done.
[reply]
(Ovid - IIS is pitiful) Re: IIS and Apache
by Ovid (Cardinal) on Dec 27, 2000 at 02:23 UTC
    In the event that anyone stumbles across this looking for help, I figured I would provide a follow-up. This link is a Microsoft bug report that covers 3 (yup, three!) versions of IIS. It (incorrectly) states that IIS ignores the Set-Cookie header if used with a Location: header. In reality, it passes the Set-Cookie: header but tosses an extra newline in the headers prior to the status line.

    merlyn's comment that he thought IIS might always require nph- headers, while not quite accurate, is pretty close to the mark. I discovered that merely trying to generate a Status: header had the same effect of breaking up the headers. 

        print $cgi->header( -cookie => \@cookie,
                        -status => $status );

    [download]
    The above snippet generated the following: 
    HTTP/0.9 200 OK
Client-Date: Tue, 26 Dec 2000 20:04:30 GMT
Client-Peer: 192.168.1.65:80

Status: 403 Forbidden
Set-Cookie: orderTotal=n%2Fa; path=/
Set-Cookie: message=No%20such%20dealer.; path=/
Date: Tue, 26 Dec 2000 21:01:26 GMT
Content-Type: text/html; charset=ISO-8859-1

    [download]
    It appears that IIS wants to insert its own status code regardless of the status that I provide. Using nph with IIS appears to be desirable due to many bugs.

    Incidentally, using the same script with Apache resulted in a 403 Forbidden response, as desired, but failed to send cookies. Is this appropriate? I didn't see anything in the cookie specification that prevents them from being set with a 403 error.

    Cheers,
    Ovid

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom