Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Re: Cookie Hell

by TexasTess (Beadle)
on Jul 07, 2002 at 01:02 UTC ( #179912=note: print w/replies, xml ) Need Help??

in reply to Cookie Hell

Can't post the's at work...can't post to the net from work...can't bring my work home. I'm not using so I am using the set-Cookie:foo=blah;expires=blah method.

Since I posted I have thought of a couple syntax errors that could be the latest culprit...but what I usually end up with is the cookie line printing literally in the produced webpage (I am using pure CGI to generate all my HTML dynamically) OR the headers line prints to the page literally.

I've found that you can't interchange the and raw form code ....once you use a $foo = new CGI all form data that is parsed ends up in the $foo->param variable ...

So thoughts about being able to "unset" headers once their set?

Great Spirits often encounter violent opposition from mediocre minds" --Einstein

Replies are listed 'Best First'.
Re: Re: Cookie Hell
by Mr. Muskrat (Canon) on Jul 07, 2002 at 01:09 UTC

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

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

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

    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.
      The meat of the program is working like a charm and does not use To convert it would mean days and days of work that I don't have time for...I agree that 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 but can't get a simple cookie to set ?


        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=/;

        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.

        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.

        Do you mind if I ask what version of perl you're using? I seem to remember 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 installed....


Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://179912]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (3)
As of 2023-09-27 09:45 GMT
Find Nodes?
    Voting Booth?

    No recent polls found