in reply to Re: Cookie Hell
in thread Cookie Hell

I've found that you can't interchange the CGI.pm and raw form code

Why would you want to? It's much safer to let CGI.pm take care of it for you.

I think that you could solve your problems by upgrading your code to use CGI.pm.

My thoughts are mine and mine alone. They did not originate with the voices in my head. Do not listen to what they say, it's all lies.

Replies are listed 'Best First'.
Re: Re: Re: Cookie Hell
by TexasTess (Beadle) on Jul 07, 2002 at 01:19 UTC
    The meat of the program is working like a charm and does not use CGI.pm. To convert it would mean days and days of work that I don't have time for...I agree that CGI.pm is very cool, but we didn't get it approved for installation until I'd gotten most of the project working.

    I hate to think that I can get a database flatfile script to work....XORing passwords and validating entries without CGI.pm but can't get a simple cookie to set ?

    TexasTess
[reply]

      While red tape is uncool, we're stuck with the current state of affairs. One strategy is printing set-cookie headers, like this:

      Set-Cookie: VarName=Value;path=/;domain=.mydomain.com

      Of course, this does absolutely nothing in the way of fine details like escaping values, etc. (The CGI module does all of this automatically when used correctly.) Escaping variable names is particularly unstable: I've seen cases where different versions of IE/NS had different ideas about whether to stomp underscores in variable names before sending them.

      Another idea to consider is a very minimal use of the CGI module. That is: refactor the acquisition of variable/cookie names and values, and use print $q->header and its variants, and $VarName = $q->cookie(...) to properly construct the cookies...but leave all generation of HTML proper as-is (print to STDOUT is typical). I personally am accustomed to editing HTML in a programming file editor rather than a GUI environment, so I have no immediate pressure to use any of the HTML-generating shortcuts.

[reply]
[d/l]
[select]
      While this isn't very constructive, I have to doubt the fact that it works like a charm. How unusual are the queries you've hit it with? Will it work for both GET and POST requests? What about multipart/form-data? Does it gracefully handle multiple query keys? That's just the most common problems I can think of off the top of my head. See Ovid's excellent CGI course for good - nay, required - practice when writing CGI scripts.

      Makeshifts last the longest.

[reply]
        Well, I solved the issue today at work, one problem was that I realised I had the wrong day of the week listed for the date/year combo in the expires list.

        Another step I took was to remove the arbitrary &print_headers call that occurred at the beginning of the script and place it within subs that would require a header to print

        Then I had to play with the path a bit...I don't have admin rights...am a systems engineer doing software engineering for my boss as a "freebie"..as a result my code is outside of the cgi-bin and my paths are all over the damn place until the program goes prime time..thus the path=/ option had to be massaged a bit ...

        TexasTess
        "Great Spirits Often Encounter Violent Opposition From Mediocre Minds" --Einstein
[reply]
      Do you mind if I ask what version of perl you're using? I seem to remember CGI.pm being added to the core distribution somewhere around 5.004, which was like 5 years ago. Any reasonably recent distribution of perl should already come with CGI.pm installed....

      -Blake

[reply]
        I'll have to check..it's 5.something...and it might have been "installed" but it wasn't functional...don't ask why..I don't have admin rights on the server all I know is it didn't work...then all of a sudden it appeared after I cried enough..and it started working :-)
[reply]

In Section Seekers of Perl Wisdom