[16140] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 3552 Volume: 9

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jul 10 15:27:31 2000

Date: Mon, 10 Jul 2000 12:27:19 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <963257239-v9-i3552@ruby.oce.orst.edu>
Content-Type: text

Perl-Users Digest           Mon, 10 Jul 2000     Volume: 9 Number: 3552

Today's topics:
        Can scripts find out computer's name? <danielcho22@usa.net>
    Re: Can scripts find out computer's name? (David Efflandt)
    Re: Can scripts find out computer's name? <emil.rakoczy@telenor.com>
    Re: Can scripts find out computer's name? <danielcho22@usa.net>
    Re: Can scripts find out computer's name? (brian d foy)
        Can't dereference for AUTOLOAD <chuckwNOchSPAM@silverlink.net.invalid>
    Re: Can't dereference for AUTOLOAD <aqumsieh@hyperchip.com>
        capturing STDERR from an external command ken_ross@my-deja.com
    Re: capturing STDERR from an external command <bwalton@rochester.rr.com>
        Carpout, warnings to browser? (zawy)
    Re: Carpout, warnings to browser? <bwalton@rochester.rr.com>
    Re: Carpout, warnings to browser? (zawy)
    Re: Carpout, warnings to browser? (zawy)
    Re: Carpout, warnings to browser? (zawy)
    Re: Carpout, warnings to browser? <bwalton@rochester.rr.com>
    Re: Carpout, warnings to browser? <tina@streetmail.com>
    Re: catch error SQL <cplee@bigfoot.com>
        Certain modules start working after upgrade to Perl 5.6 <dmitryp@attglobal.net>
    Re: Certain modules start working after upgrade to Perl (jason)
    Re: Certain modules start working after upgrade to Perl <gellyfish@gellyfish.com>
    Re: CGI and cookies <gellyfish@gellyfish.com>
    Re: CGI and cookies <srevilak@cs.umb.edu>
        cgi Help <donald@donald8.freeserve.co.uk>
    Re: cgi Help <pap@sotonians.org.uk>
        Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Fri, 07 Jul 2000 02:32:04 GMT
From: Cho <danielcho22@usa.net>
Subject: Can scripts find out computer's name?
Message-Id: <smag94ggas120@corp.supernews.com>

hi,

I was wondering if it was possible for perl or anything to find out the 
computer name of the user who is viewing a web page. You know, kind of 
like an enviroment variable -- instead of remote address, there must be 
some way to find out the name of the computer.

Any ideas?

Thanks,

Daniel

--
Posted via CNET Help.com
http://www.help.com/


------------------------------

Date: 7 Jul 2000 04:30:32 GMT
From: efflandt@xnet.com (David Efflandt)
Subject: Re: Can scripts find out computer's name?
Message-Id: <slrn8man72.le7.efflandt@efflandt.xnet.com>

On Fri, 07 Jul 2000 02:32:04 GMT, Cho <danielcho22@usa.net> wrote:
>
>I was wondering if it was possible for perl or anything to find out the 
>computer name of the user who is viewing a web page. You know, kind of 
>like an enviroment variable -- instead of remote address, there must be 
>some way to find out the name of the computer.

No.  For example say I am accessing your website from my laptop on a
private IP address 192.168.1.2, networked to a Linux box and being
masqueraded as an internet IP.  Or suppose someone at AOL accesses your
site, they all go through a bank of web proxies, so the request appears to
come from the web proxy, which in turn hands off the result to the user.  
So you don't really have a clue what machine or user is making the
request or where in the world they are.  It could be some guy in Germany
on a dialup to compuserve.com that you think is in Ohio, or maybe those
same proxies AOL uses, since CompuServe is owned by AOL.

-- 
David Efflandt  efflandt@xnet.com  http://www.de-srv.com/
http://www.autox.chicago.il.us/  http://www.berniesfloral.net/
http://hammer.prohosting.com/~cgi-wiz/  http://cgi-help.virtualave.net/



------------------------------

Date: Fri, 7 Jul 2000 09:14:26 +0200
From: "Emil Rakoczy" <emil.rakoczy@telenor.com>
Subject: Re: Can scripts find out computer's name?
Message-Id: <8k4014$61i@info.telenor.no>

David Efflandt skrev i meldingen ...
>On Fri, 07 Jul 2000 02:32:04 GMT, Cho <danielcho22@usa.net> wrote:
>>
>>I was wondering if it was possible for perl or anything to find out the
>>computer name of the user who is viewing a web page. You know, kind of
>>like an enviroment variable -- instead of remote address, there must be
>>some way to find out the name of the computer.
>
>No.  For example say I am accessing your website from my laptop on a
>private IP address 192.168.1.2, networked to a Linux box and being
>masqueraded as an internet IP.  Or suppose someone at AOL accesses your
>site, they all go through a bank of web proxies, so the request appears to
>come from the web proxy, which in turn hands off the result to the user.
>So you don't really have a clue what machine or user is making the
>request or where in the world they are.  It could be some guy in Germany
>on a dialup to compuserve.com that you think is in Ohio, or maybe those
>same proxies AOL uses, since CompuServe is owned by AOL.
>
I'm on very thin ice here... but can't you plant some cookie or scripts on
the visiting machine? I'm sure there got to be other ways than what you are
describing. Because you can force feed the client with data from the server,
there should be a way of finding out more than nothing about your visitor.
The visiting browser also sends out alot of default information when you
check out a site. Maybe some of that could be useful. Don't know more than
this about this subject, but I hope it helps some anyhow.

Emil, Norway




------------------------------

Date: Fri, 07 Jul 2000 18:30:09 GMT
From: Cho <danielcho22@usa.net>
Subject: Re: Can scripts find out computer's name?
Message-Id: <smc8dhalnu21@corp.supernews.com>

thanks guys,

i've got another idea that i hoped would work.

There's something in dos called nbtstat which in a network allows you to 
find out the computer's name given an ip address. Now, for within this 
network alone, i think i will be able to get the ip address of the 
computer, then use nbtstat from the script to find out the computer's name.

for example:
 $remote_addr=148.89.888.55
 #Then use nbtstat somehow to do...
 nbtstat -A $remote_addr (or 148.89.888.55)

the problem is, is it possible to access dos' nbtstat from a script??

thanks.


--
Posted via CNET Help.com
http://www.help.com/


------------------------------

Date: Fri, 07 Jul 2000 18:08:17 -0400
From: brian@smithrenaud.com (brian d foy)
Subject: Re: Can scripts find out computer's name?
Message-Id: <brian-ya02408000R0707001808170001@news.panix.com>

In article <smc8dhalnu21@corp.supernews.com>, Cho <danielcho22@usa.net> posted:

> There's something in dos called nbtstat which in a network allows you to 
> find out the computer's name given an ip address.

have you tried the gethost* functions documented in perlfunc?

> the problem is, is it possible to access dos' nbtstat from a script??

you could use backticks to run an external program and save the output.

-- 
brian d foy                    
CGI Meta FAQ <URL:http://www.smithrenaud.com/public/CGI_MetaFAQ.html>
Perl Mongers <URL:http://www.perl.org/>


------------------------------

Date: Fri, 07 Jul 2000 11:17:31 -0700
From: chuckw <chuckwNOchSPAM@silverlink.net.invalid>
Subject: Can't dereference for AUTOLOAD
Message-Id: <19d173c4.129bce35@usw-ex0104-033.remarq.com>

I just encountered something very strange and I wondering anyone
can show me what I am doing wrong or confirm that I have found
some sort of perl-ism (or possibly a *gasp* bug).

The following chunk of code does NOT work:

1. $arrayRef  = \@array;
2. for ($i=1;$i<=$#$arrayRef;$i++) {
3.    print "Array item: ", $objectRef->$$arrayRef[$i]() , "\n";
4. }


Specifically line 3 is what I am trying to demonstrate (if you
find other bugs in the code, please ignore them and take the
spirit of what I was TRYING to say).

The error message I get with this is:

  syntax error at MyNewModule.pm line XXX, near "$arrayRef["
  BEGIN failed--compilation aborted at ./test.pl line 4.


The following hack (lines 3 and 4) gets around the limitation
and works just fine:

1. $arrayRef  = \@array;
2. for ($i=1;$i<=$#$arrayRef;$i++) {
3.    $data = $$arrayRef[$i];
4.    print "Array item: ", $objectRef->$data() , "\n";
5. }


Any ideas on why this is happening?

To respond directly remove the obvious from the following:

S1P2A3Mchuckw@S1P2A3Msilverlink.S1P2A3Mnet


-----------------------------------------------------------

Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com



------------------------------

Date: Fri, 07 Jul 2000 18:44:11 GMT
From: Ala Qumsieh <aqumsieh@hyperchip.com>
Subject: Re: Can't dereference for AUTOLOAD
Message-Id: <7aya3dlqzm.fsf@merlin.hyperchip.com>


chuckw <chuckwNOchSPAM@silverlink.net.invalid> writes:

> I just encountered something very strange and I wondering anyone
> can show me what I am doing wrong or confirm that I have found
> some sort of perl-ism (or possibly a *gasp* bug).
> 
> The following chunk of code does NOT work:
> 
> 1. $arrayRef  = \@array;
> 2. for ($i=1;$i<=$#$arrayRef;$i++) {
> 3.    print "Array item: ", $objectRef->$$arrayRef[$i]() , "\n";
> 4. }
> 
> 
> Specifically line 3 is what I am trying to demonstrate (if you
> find other bugs in the code, please ignore them and take the
> spirit of what I was TRYING to say).
> 
> The error message I get with this is:
> 
>   syntax error at MyNewModule.pm line XXX, near "$arrayRef["
>   BEGIN failed--compilation aborted at ./test.pl line 4.
> 
> 
> The following hack (lines 3 and 4) gets around the limitation
> and works just fine:
> 
> 1. $arrayRef  = \@array;
> 2. for ($i=1;$i<=$#$arrayRef;$i++) {
> 3.    $data = $$arrayRef[$i];
> 4.    print "Array item: ", $objectRef->$data() , "\n";
> 5. }
> 
> 
> Any ideas on why this is happening?

Yep. Precedence problems. Change your line 3 to:

	$objectRef->${\$arrayRef->[$i]}()

But, this is the not the Perl way to do it. If you don't need to know
the index (ie, you don't need the value of $i explicitly), then you can
iterate through the array like so:

	for my $data (@$arrayRef) {
		print "Array item: ", $objectRef->$data(), "\n";
	}

--Ala


------------------------------

Date: Wed, 05 Jul 2000 16:29:25 GMT
From: ken_ross@my-deja.com
Subject: capturing STDERR from an external command
Message-Id: <8jvnob$f4e$1@nnrp1.deja.com>

My coworker is able to read standard error from an external command
without using "2>&1", yet I am not.  Her statement, which is in a .pm
module, is:
  open LOGIN_REC, "ftp -n <<INLINE\n$ftp_cmd\nINLINE |";  #her code

This does not work for me.  To get this to work, I have to use the
following:
   open LOGIN_REC, "2>&1 ftp -n <<INLINE\n$ftp_cmd\nINLINE |";  #my code

When she tried my code and then reverted back to hers, all of a sudden
she was unable to read standard error.  Then she did something - we
don't know what - which caused her code to be able to read standard
error again without the redirection, as if by magic.   Does anyone have
an idea of what may be going on?


Sent via Deja.com http://www.deja.com/
Before you buy.


------------------------------

Date: Wed, 05 Jul 2000 21:04:03 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re: capturing STDERR from an external command
Message-Id: <3963A31B.8BC3985E@rochester.rr.com>

ken_ross@my-deja.com wrote:
> 
> My coworker is able to read standard error from an external command
> without using "2>&1", yet I am not.  Her statement, which is in a .pm
> module, is:
>   open LOGIN_REC, "ftp -n <<INLINE\n$ftp_cmd\nINLINE |";  #her code
> 
> This does not work for me.  To get this to work, I have to use the
> following:
>    open LOGIN_REC, "2>&1 ftp -n <<INLINE\n$ftp_cmd\nINLINE |";  #my code
> 
> When she tried my code and then reverted back to hers, all of a sudden
> she was unable to read standard error.  Then she did something - we
> don't know what - which caused her code to be able to read standard
> error again without the redirection, as if by magic.   Does anyone have
> an idea of what may be going on?
 ...
Just because you keep posting this doesn't mean we will be able to
answer it any better.  Do you have any more details, like what platform,
what OS, what OS version, what Perl version, etc?  Are the two machines
the same?  Same shell?  Same environment variable settings?  You are
really asking a Unix question, and one that might be pretty specific to
your particular flavor of Unix, right down to what your default shell
is, what aliases are in effect, etc.
-- 
Bob Walton


------------------------------

Date: Sat, 08 Jul 2000 17:04:21 GMT
From: zawy@yahoo.com (zawy)
Subject: Carpout, warnings to browser?
Message-Id: <39675bc8.174676035@news.mindspring.com>

For debugging,
use CGI::Carp qw( fatalsToBrowser carpout); 
is good, and 

BEGIN { 
use CGI::Carp qw(carpout);  
open(LOG, ">>/web/mydomain/cgi-bin/_error.html") or
          die("Unable to open mycgi-log: $!\n");  
carpout(LOG);  
}

is better, but how do I get the last one to go to my browser instead
of a file (for inital, pre-public versions)?

Several web pages claim the following works, but it didn't work for me
(crapped out my programs).  

$SIG{``__DIE__''} = $SIG{``__WARN__''} = sub {
            my $error = shift;
            chomp $error;
            $error =~ s/[<&>]/``&#''.ord($&).``;''/ge;  # entity
escape;
            print ``Content-type: text/html\n\n[$error]\n'';
            exit 0;
          };


------------------------------

Date: Sun, 09 Jul 2000 00:17:21 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re: Carpout, warnings to browser?
Message-Id: <3967C4D2.8F517828@rochester.rr.com>

zawy wrote:
> 
> For debugging,
> use CGI::Carp qw( fatalsToBrowser carpout);
> is good, and
> 
> BEGIN {
> use CGI::Carp qw(carpout);
> open(LOG, ">>/web/mydomain/cgi-bin/_error.html") or
>           die("Unable to open mycgi-log: $!\n");
> carpout(LOG);
> }
> 
> is better, but how do I get the last one to go to my browser instead
> of a file (for inital, pre-public versions)?
> 
> Several web pages claim the following works, but it didn't work for me
> (crapped out my programs).

Somehow you got goofed up on quoting.  Try the changes indicated below
[untested]:

> 
> $SIG{``__DIE__''} = $SIG{``__WARN__''} = sub {

  $SIG{"__DIE__") =   $SIG{"__WARN__"}   = sub {

>             my $error = shift;
>             chomp $error;
>             $error =~ s/[<&>]/``&#''.ord($&).``;''/ge;  # entity

              $error =~ s/[<&>]/"&#".ord($&).";"/ge;  # entity

> escape;
>             print ``Content-type: text/html\n\n[$error]\n'';

              print "Content-type: text/html\n\n[$error]\n";

>             exit 0;
>           };
-- 
Bob Walton


------------------------------

Date: Sun, 09 Jul 2000 03:35:16 GMT
From: zawy@yahoo.com (zawy)
Subject: Re: Carpout, warnings to browser?
Message-Id: <3967f2d7.213352791@news.mindspring.com>

>Somehow you got goofed up on quoting.  Try the changes indicated below

Yes, I tried that (assuming those are all double quotes and not double
single quotes).   I just copied and pasted from one the web pages.
All the web pages on this appeared screwed up (double backticks and
double single quotes for all double quotes.  I can't figure out why
they did that.


------------------------------

Date: Sun, 09 Jul 2000 04:14:55 GMT
From: zawy@yahoo.com (zawy)
Subject: Re: Carpout, warnings to browser?
Message-Id: <3967f4cb.213853196@news.mindspring.com>

The following worked, and it worked a lot better than FatalsToBrowser
but not as good as the error output file described in the initial
post.  

Besides correcting the code to use double-quotes, I needed to take the
brackets off from around the $error.  I can't figure out why they
would include those mistakes.  I think I saw the exact same erroneous
code on 3 web pages.  

use CGI::Carp qw( fatalsToBrowser carpout);    Blocks the warnings
even if the BEGIN shown below is used and -w needs to be on.

BEGIN {
$SIG{"__DIE__"}  = $SIG{"__WARN__"} = sub {
my $error = shift;
chomp $error;
$error =~ s/[<&>]/"&#".ord($&).";"/ge; 
print "Content-type: text/html\n\n$error\n";
exit 0; }
}



------------------------------

Date: Sun, 09 Jul 2000 13:22:03 GMT
From: zawy@yahoo.com (zawy)
Subject: Re: Carpout, warnings to browser?
Message-Id: <39687848.247519057@news.mindspring.com>

Why doesn't the following go into the while loop?

BEGIN { 
use CGI::Carp qw(carpout);  
open(LOG, ">/local/error.log") or  die("Unable to open log: $!\n");  
carpout(LOG); 		# errors are posted as expected
close LOG;   		# same results with or without this
print "Content-type:text/html\n\n<html><body> this shows up"; 
open(LOG, "/local/error.log") or  die("Unable to open log: $!\n"); 
print "this shows up";
while (<LOG>) {
print "$_ this text and variable never show"; 
}
close LOG;
}


------------------------------

Date: Mon, 10 Jul 2000 02:40:33 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re: Carpout, warnings to browser?
Message-Id: <396937E4.CF4FE581@rochester.rr.com>

zawy wrote:
> 
> Why doesn't the following go into the while loop?
> 
> BEGIN {
> use CGI::Carp qw(carpout);
> open(LOG, ">/local/error.log") or  die("Unable to open log: $!\n");
> carpout(LOG);           # errors are posted as expected
> close LOG;              # same results with or without this
> print "Content-type:text/html\n\n<html><body> this shows up";
> open(LOG, "/local/error.log") or  die("Unable to open log: $!\n");
> print "this shows up";
> while (<LOG>) {
> print "$_ this text and variable never show";
Well, you opened /local/error.log for writing (which clobbers it), then
never wrote anything to it, then closed it, then opened it for reading,
and there is nothing in it, so the while loop falls through without
executing the print.
> }
> close LOG;
> }
-- 
Bob Walton


------------------------------

Date: 10 Jul 2000 17:20:48 GMT
From: Tina Mueller <tina@streetmail.com>
Subject: Re: Carpout, warnings to browser?
Message-Id: <8kd0lg$27h5l$1@ID-24002.news.cis.dfn.de>

hi,
Bob Walton <bwalton@rochester.rr.com> wrote:
> zawy wrote:
>> 
>> BEGIN {
>> use CGI::Carp qw(carpout);
>> open(LOG, ">/local/error.log") or  die("Unable to open log: $!\n");
>> carpout(LOG);           # errors are posted as expected
>> close LOG;              # same results with or without this
>> print "Content-type:text/html\n\n<html><body> this shows up";
>> open(LOG, "/local/error.log") or  die("Unable to open log: $!\n");
>> print "this shows up";
>> while (<LOG>) {
>> print "$_ this text and variable never show";
> Well, you opened /local/error.log for writing (which clobbers it), then
> never wrote anything to it,

why that? there will be something in in error.log, or
am I missing something?


tina

-- 
http://tinita.de    \  enter__| |__the___ _ _ ___
tina's moviedatabase \     / _` / _ \/ _ \ '_(_-< of
search & add comments \    \ _,_\ __/\ __/_| /__/ perception
"The Software required Win98 or better, so I installed Linux."


------------------------------

Date: Mon, 03 Jul 2000 23:58:50 -0700
From: ChungpingLi <cplee@bigfoot.com>
Subject: Re: catch error SQL
Message-Id: <39618B29.6CCD5A28@bigfoot.com>

$sth=$dbh->prepard($sql);
$sth->bind_param(1,$baz);
$sth->execute();

eastking@my-deja.com wrote:

> Hi,every one here.
>
> I'm using DBI and DBD::Oracle to access database. when I use following
> source
>
>          $sth = $dbh->prepare("select foo, bar from table where
> baz=?");
>
>          $sth->execute( $baz );
>
>          while ( @row = $sth->fetchrow_array ) {
>            print "@row\n";
>          }
>
> If execution failed, How can I know the whole SQL with "?" replaced
> with $baz?
>
> I don't think following is the best idea
>
>         my $sql = "select foo, bar from table where baz=?";
>
>          $sth = $dbh->prepare($sql);
>
>          $sth->execute( $baz );
>
>          while ( @row = $sth->fetchrow_array ) {
>            print "@row\n";
>          }
>
>         $sql =~ s/\?/$baz/ ;
>
> Thanks in advance
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--
A. R. Tech Communication
6814 S. Parker Rd. Foxfield CO 80016
U.S.A. Tel (888)308-9898 Fax (888)860-7594
Andy@bigfoot.com




------------------------------

Date: Fri, 7 Jul 2000 15:39:08 +0100
From: "Dmitry Podborits" <dmitryp@attglobal.net>
Subject: Certain modules start working after upgrade to Perl 5.6.0
Message-Id: <39663189$0$16349@wodc7nh1.news.uu.net>

One example of that is IO::Socket::SSL. It now produces a run-time error
about not being able to resolve a method call.

I wonder if this is a known problem and if the bug is attributed to the Perl
itself or the modules and what can be done to fix it.

Thanks in advance for any update.

Best regards,
Dmitry





------------------------------

Date: Sat, 08 Jul 2000 01:21:39 GMT
From: elephant@squirrelgroup.com (jason)
Subject: Re: Certain modules start working after upgrade to Perl 5.6.0
Message-Id: <MPG.13d11f6757b862fc989775@news>

Dmitry Podborits writes ..
>One example of that is IO::Socket::SSL. It now produces a run-time error
>about not being able to resolve a method call.

guessing for a second that your subject line meant to say "stop" instead 
of "start" .. this is no mystery .. there is no binary compatibility 
guarantee between versions of Perl .. meaning that if a module uses XS 
components then they may need to be recompiled with the newer version of 
Perl

that having been said .. there's no guarantee that they will compile 
with the new version of Perl .. not until some bright bunny makes the 
necessary changes to the build process or to the source

-- 
 jason - elephant@squirrelgroup.com -


------------------------------

Date: 8 Jul 2000 14:27:29 +0100
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: Certain modules start working after upgrade to Perl 5.6.0
Message-Id: <8k7a81$oe2$1@orpheus.gellyfish.com>

On Sat, 08 Jul 2000 01:21:39 GMT jason wrote:
> Dmitry Podborits writes ..
>>One example of that is IO::Socket::SSL. It now produces a run-time error
>>about not being able to resolve a method call.
> 
> guessing for a second that your subject line meant to say "stop" instead 
> of "start" .. this is no mystery .. there is no binary compatibility 
> guarantee between versions of Perl .. meaning that if a module uses XS 
> components then they may need to be recompiled with the newer version of 
> Perl
> 
> that having been said .. there's no guarantee that they will compile 
> with the new version of Perl .. not until some bright bunny makes the 
> necessary changes to the build process or to the source
> 

Most just need POLLUTE=1 to be supplied to Makefile.PL 

/J\
-- 
yapc::Europe in assocation with the Institute Of Contemporary Arts
   <http://www.yapc.org/Europe/>   <http://www.ica.org.uk>


------------------------------

Date: 4 Jul 2000 09:09:29 +0100
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: CGI and cookies
Message-Id: <8js63p$dud$1@orpheus.gellyfish.com>

On Mon, 03 Jul 2000 13:24:08 GMT snakedjip@yahoo.com wrote:
> In article <slrn8m0dhc.tfv.garcia_suarez@rafael.kazibao.net>,
>   garcia_suarez@hotmail.com (Rafael Garcia-Suarez) wrote:
>> snakedjip@my-deja.com wrote in comp.lang.perl.misc:
>> >I'm experiencing some weird behavior, and i'm looking for ideas to
>> >guide me...
>> >
>> >I have a web site.  I use cookies to check if a user is logged in or
>> >not.
>> >
>> >In development (on my PC) AND in production (at my hosting service), I
>> >have no problem with this setup using my PC as the browser, whether it
>> >be with Netscape or IE.  Cookies are being set, users are being
>> >recognized (I turned prompts on for cookies in the browsers).
>> >
>> >When I go to my friend's PC, the cookies are simply not set.  He had
>> >only IE installed, it didn't work, so I installed Netscape, turned on
>> >the cookie prompts, and NOTHING.
>> >
>> >I went to another site that uses cookies, and those sites worked fine
>> >on his PC.
>> >
>> >By the way, he's on ADSL, and his ISP uses some kind of proxy to limit
>> >bandwidth consumption.  Could this be the reason ???????
>>
>> A proxy can do one of those things :
>>   * filtering out Set-Cookie headers in HTTP requests
>>   * Changing domain names while transmitting HTTP requests (e.g. to IP
>>     addresses)
>> Put a simple script that prints %ENV on your web site, and look if all
>> variables look normal (esp. HTTP_HOST).
>>

Did you do this ?

>
> I have just tried Netscape at work, and it gives me the same behavior
> as with my friend's PC, e.g. it doesn't work (the cookies are not set).
> 
> With IE on the same PC, everything is fine.
> 
> So, it's probably not a proxy issue...
> 

If it works fine on one PC and not another then it probably isnt a Perl
issue either - possibly you are sending a cookie that is not compatible
with certain browsers - you might will want to ask in the newsgroup
comp.infosystems.www.authoring.cgi about this as I would imagine that it
would be the same whatever language you were using.

/J\
-- 
** This space reserved for venue sponsor for yapc::Europe **
              <http://www.yapc.org/Europe/> 


------------------------------

Date: Tue, 4 Jul 2000 09:54:13 -0400
From: Steve Revilak <srevilak@cs.umb.edu>
Subject: Re: CGI and cookies
Message-Id: <Pine.GSO.4.05.10007040948350.17705-100000@eris.cs.umb.edu>

On Mon, 3 Jul 2000 snakedjip@yahoo.com wrote:

/ I have just tried Netscape at work, and it gives me the same behavior
/ as with my friend's PC, e.g. it doesn't work (the cookies are not set).
/ 
/ With IE on the same PC, everything is fine.
/ 
/ So, it's probably not a proxy issue...
/ 
/ Any other ideas ?

Things I'd try to check.

Are you explicitly setting fields other than the basic name/value
pair?

Does the HTTP header look ok?  A simple way to look is by telneting to
port 80 of the host in question and sending the request by hand.

   % telnet apache.org 80
   Trying 63.211.145.10...
   Connected to apache.org.
   Escape character is '^]'.
   GET http://www.apache.org HTTP/1.0
   
   HTTP/1.1 200 OK
   Date: Tue, 04 Jul 2000 13:47:49 GMT
   Server: Apache/1.3.9 (Unix) ApacheJServ/1.1 PHP/3.0.12 AuthMySQL/2.20
   Cache-Control: max-age=86400
   Expires: Wed, 05 Jul 2000 13:47:49 GMT
   Connection: close
   Content-Type: text/html
 
(an even simpler way is to run your cgi script from the command line
and see what comes out).

You might also want to check RFC 2109 "HTTP State Management
Mechanism" as well.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steve Revilak
srevilak@cs.umb.edu



------------------------------

Date: Thu, 6 Jul 2000 16:07:49 +0100
From: "Donald Marshall" <donald@donald8.freeserve.co.uk>
Subject: cgi Help
Message-Id: <8k27hl$qlm$1@newsg1.svr.pol.co.uk>

Hi can anyone help me I am a newcommer to CGI and am looking for help
writing some scripts including Guestbooks, Message Boards, Form to E Mail
scripts counters and Link Counters and a File Upload page any help would be
greatly appreciated. Thanks very Much

--
Donald Marshall
www.specialforcesgames.co.uk
for all your Special Forces Game Needs




------------------------------

Date: Thu, 06 Jul 2000 16:29:55 +0000
From: "Paul Taylor" <pap@sotonians.org.uk>
Subject: Re: cgi Help
Message-Id: <CE195.69$_l.4051@nnrp3.clara.net>

In article <8k27hl$qlm$1@newsg1.svr.pol.co.uk>, "Donald Marshall"
<donald@donald8.freeserve.co.uk> wrote:
> Hi can anyone help me I am a newcommer to CGI and am looking for help
> writing some scripts including Guestbooks, Message Boards, Form to E
> Mail scripts counters and Link Counters and a File Upload page any help
> would be greatly appreciated. Thanks very Much

Why not....

Go off and read some Perl documentation.

Look at general principles of CGI.

Look at sites like www.cgi-resources.com, etc - to see if anyone else
has ever thought of / written stuff like BBS's or Link counters.

Design the systems that you choose to write yourself.

Attempt the code implementation of those systems in a language of 
choice ( not necessarily Perl, because Perl and CGI aren't 
interchangeable terms, funnily enough ).

Get back to the newsgroup if you have a problem which is reasonably
less vague than the one you have right now, if it involves Perl.

Pap
(Oh my God I'm one of them)


------------------------------

Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 16 Sep 99)
Message-Id: <null>


Administrivia:

The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc.  For subscription or unsubscription requests, send
the single line:

	subscribe perl-users
or:
	unsubscribe perl-users

to almanac@ruby.oce.orst.edu.  

| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.

For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V9 Issue 3552
**************************************


home help back first fref pref prev next nref lref last post