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

Monks ~

Brief summary

  1. Is there a Perl way to set cookies after the HTTP header has been written?
  2. Is there a Perl way to read cookies without initiating a new page request?

Details

I'm looking for a little more flexibility in setting and reading cookies. First, here are what I consider to be CGI.pm's limitations. If I'm wrong about these, then the rest of my assumptions are flawed as well.

I'm not sure about the final point; I think it's more a limitation of the "magic cookie" spec than of CGI.pm. As I understand it, the user agent sends cookie information with each page request. This would indicate to me that there's no way to read a cookie without the user agent initiating a new request. I've done some simple tests which seem to confirm this, but perhaps there's another WTDI.

My other question is, How can I set cookies other than at HTTP header write time? What makes me think this is possible is that some annoying sites *cough*ZDNet*cough* appear to attempt to set a cookie with every image, long after the page header has been sent and displayed. Also, so-called 3rd-party cookies would have to work outside the page header as well, since they're usually set with banner ads or web bugs.

Am I misunderstanding what's happening here, or are these cookies really being set independent of the HTTP header? (I know you can set cookies with JavaScript, but like a one-fingered man can do calculus on an abacus - slowly and unreliably.)

Thanks muchly,
--
man with no legs, inc.

Replies are listed 'Best First'.
Re: Cookie flexibility and limitations
by lestrrat (Deacon) on Jul 20, 2001 at 23:48 UTC

    Well, when you say that the site "appear to attempt to set a cookie with every image", remember that each image is retrieved via HTTP -- i.e., you get headers for each of the images as well.

    So I think you're seeing the cookies that come with the images, not the page the images are loaded from.

    As I understand it, in order to set cookies with HTTP messages, you *have* to do it with the header

[reply]
Re: Cookie flexibility and limitations
by simon.proctor (Vicar) on Jul 21, 2001 at 01:52 UTC
    When you are receiving content via HTTP, you are always going to get the whole header in a particular format. To set a cookie, you are required to send it as part of this header but before the content type is passed to the browser. i.e.: 

    Set-Cookie: blahblahblah
Content-type: text/html

<html>
.....

    [download]


    Where blahblahblah is the properly formatted cookie information. When banner adverts print their info, they do something along the lines of (but possibly not exactly - hey its only an example :P) 

    Set-Cookie: blahblahblah
Content-type: image/gif
....
<data>

    [download]


    Although the cookie section is not part of the HTTP spec (according to my O'Reilly book) - everyone uses it (as we all well know :P).

    So if you want to do something after the page has been displayed, you're best bet is to have a perl script that delivers a blank image with the cookie as part of its transaction to the browser. i.e: 

      <img src="http://www.mysite.blob/cgi-bin/imager.pl?IMAGE=one">

    [download]


    As far as I know - this is the only way you can have cookies from one site set by another (by the second site including that image).

    Hope that helps - if not - reply and I'll see what I can do :)
[reply]
[d/l]
[select]
      That's very helpful, thanks. What I missed in my thinking was that images can be served with their own HTTP header. It all makes sense now.
      --
      man with no legs, inc.
[reply]
Re: Cookie flexibility and limitations
by rucker (Scribe) on Jul 20, 2001 at 23:50 UTC
    Yes you need to write the cookies in the header. Perhaps you should write the header after you know what you're going to put in it? You should be able to retrieve a cookie as many times in your script as you want.
[reply]

Back to Seekers of Perl Wisdom