Loading ...
Sorry, an error occurred while loading the content.

Re: Cookies, CGI::App, and mod_perl

Expand Messages
  • Perrin Harkins
    ... Do some debugging. Look at the traffic going back and forth. Test it with GET or lynx. See if the cookie header is being sent. ... Right, although I
    Message 1 of 5 , Aug 1 10:14 AM
    • 0 Attachment
      On Fri, 2003-08-01 at 13:04, petersm wrote:
      > When running under mod_perl the cookie is no
      > where to be seen.

      Do some debugging. Look at the traffic going back and forth. Test it
      with GET or lynx. See if the cookie header is being sent.

      > If I understand this correctly, then C::A uses CGI to set
      > the cookie and CGI should set it correctly if I'm running under mod_perl right?

      Right, although I don't think C::A knows or cares at all about cookies.
      This is just between you and CGI.pm.

      > I've seen a lot on forums to use Apache::Cookie, but how do I do that within C::A?

      You don't need to use Apache::Cookie, but if you want to you should be
      able to use it in the normal documented way. C::A should not have any
      bearing on this.

      - Perrin
    • Perrin Harkins
      [ Please keep it on the list... ] ... That looks okay to me. Maybe it s something about the way you ve structured your code. Try reducing it down to a small
      Message 2 of 5 , Aug 1 11:09 AM
      • 0 Attachment
        [ Please keep it on the list... ]

        On Fri, 2003-08-01 at 14:06, petersm wrote:
        > Perrin Harkins <perrin@...> wrote
        > > Do some debugging. Look at the traffic going back and forth. Test
        > > it with GET or lynx. See if the cookie header is being sent.
        >
        > Thanks for the suggestion. I used wget and tried it with the mod_perl stuff in
        > the config and without. Without, wget gave me the header with the cookie.
        > With, wget did not have a cookie in the header. Both returned the correct HTML.
        > Maybe some a glance at my config file could help. So here's the relavant
        > portion. Thanks...
        >
        >
        > PerlModule Apache::StatINC
        > <Location /operations/projects/menagerie>
        > AddHandler perl-script .cgi
        > PerlHandler Apache::Registry
        > PerlSendHeader On
        > allow from all
        > PerlInitHandler Apache::StatINC
        > PerlSetVar StatINCDebug On
        > PerlSetEnv PERL5LIB /development/operations/projects/
        > </Location>

        That looks okay to me. Maybe it's something about the way you've
        structured your code. Try reducing it down to a small snippet that you
        can post. You may also want to ask on the CGI::Application list.

        - Perrin
      • Tom Hukins
        ... To elaborate a little on this thread: I find ethereal useful for debugging situations like this. Certain browsers (that I won t
        Message 3 of 5 , Aug 3 10:46 AM
        • 0 Attachment
          On Fri, Aug 01, 2003 at 01:14:44PM -0400, Perrin Harkins wrote:
          > On Fri, 2003-08-01 at 13:04, petersm wrote:
          > > When running under mod_perl the cookie is no
          > > where to be seen.
          >
          > Do some debugging. Look at the traffic going back and forth. Test it
          > with GET or lynx. See if the cookie header is being sent.

          To elaborate a little on this thread:

          I find ethereal <http://www.ethereal.com/> useful for debugging
          situations like this. Certain browsers (that I won't name) behave in
          quirky ways that GET or lynx won't emulate, so it's often worth
          running ethereal in the background whilst using your site with various
          browsers, then analysing TCP streams in ethereal to see exactly what's
          happening.

          Tom
        • Larry Leszczynski
          ... PlugProxy is also very good for this type of debugging: http://www.bbzzdd.com/plugproxy/ For just examining the HTTP request/response I find it easier and
          Message 4 of 5 , Aug 3 12:34 PM
          • 0 Attachment
            > > Do some debugging. Look at the traffic going back and forth. Test it
            > > with GET or lynx. See if the cookie header is being sent.
            >
            > To elaborate a little on this thread:
            >
            > I find ethereal <http://www.ethereal.com/> useful for debugging
            > situations like this. Certain browsers (that I won't name) behave in
            > quirky ways that GET or lynx won't emulate, so it's often worth
            > running ethereal in the background whilst using your site with various
            > browsers, then analysing TCP streams in ethereal to see exactly what's
            > happening.

            PlugProxy is also very good for this type of debugging:

            http://www.bbzzdd.com/plugproxy/

            For just examining the HTTP request/response I find it easier and more
            straighforward to use than Ethereal. (The screen shot on their home page
            shows an HTTP exchange with hex mode turned on, it's actually much easier
            to read with hex mode turned off.)

            A tip for cookie testing when using PlugProxy (or similar proxying tools,
            I suppose): Generally you need to make sure you're making requests
            against the correct domain name for your browser to handle the cookies
            correctly. For example, if you set up PlugProxy on your desktop like so:

            Host: www.example.org
            Remote Port: 80
            Local Port: 8888

            then you should be able to use you browser to hit the home page with this:

            http://localhost:8888/

            *but* the browser won't send the cookies that would normally be sent to
            "example.org". The fix is to make it look like localhost is part of
            "example.org", and then make the request like this instead:

            http://localhost.example.org:8888/

            You can put something like this:

            127.0.0.1 localhost.example.org localhost

            in /etc/hosts (or <WindowsDir>\System32\drivers\etc\hosts).


            Larry Leszczynski
            larryl@...
          Your message has been successfully submitted and would be delivered to recipients shortly.