cgi-session-user Mailing List for CGI-Session (Page 6)
Brought to you by:
sherzodr
Menu
▾
▴
cgi-session-user — CGI::Session users mailing list
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
(13) |
Apr
(6) |
May
(2) |
Jun
(3) |
Jul
(2) |
Aug
(10) |
Sep
(9) |
Oct
(15) |
Nov
(1) |
Dec
(4) |
| 2004 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2005 |
Jan
(1) |
Feb
(8) |
Mar
(1) |
Apr
(1) |
May
(9) |
Jun
|
Jul
(14) |
Aug
(32) |
Sep
(34) |
Oct
(16) |
Nov
(6) |
Dec
(15) |
| 2006 |
Jan
(5) |
Feb
(27) |
Mar
(60) |
Apr
(12) |
May
(17) |
Jun
(24) |
Jul
(27) |
Aug
(16) |
Sep
(13) |
Oct
(19) |
Nov
(22) |
Dec
(29) |
| 2007 |
Jan
(23) |
Feb
(33) |
Mar
(42) |
Apr
(30) |
May
(14) |
Jun
(5) |
Jul
(12) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
(6) |
Feb
(9) |
Mar
(48) |
Apr
(20) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(9) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(11) |
Oct
(2) |
Nov
|
Dec
|
| 2010 |
Jan
(9) |
Feb
(28) |
Mar
|
Apr
(12) |
May
(13) |
Jun
|
Jul
(3) |
Aug
|
Sep
(1) |
Oct
(3) |
Nov
|
Dec
(9) |
| 2011 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(8) |
| 2015 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lee C. <lec...@ya...> - 2008-04-07 14:22:41
|
> And a public "Thanks" to Ron for keeping up the progress! Completely agree. Thanks Ron for all your hard work! Take Care, Lee |
|
From: Mark S. <ma...@su...> - 2008-04-07 14:07:52
|
Ron Savage wrote: > Hi Folks > > Look at this: http://testers.cpan.org/show/CGI-Session.html I agree. Quickly generating 41 test reports for us was very helpful. > o RT#34668. I've patched to POD for CGI::Session. Ticked closed > http://rt.cpan.org/Ticket/Display.html?id=34668 > > o RT#32932. Patched in 4.29_1, but not marked off in RT. Ticket closed > http://rt.cpan.org/Ticket/Display.html?id=32932 > > o RT#33635. Patched in 4.29_1, but not marked off in RT. Ticket closed > http://rt.cpan.org/Ticket/Display.html?id=33635 > > o RT#17299. I've patched the POD for CGI::Session. Ticket updated but > left open > http://rt.cpan.org/Ticket/Display.html?id=17299 > > o RT#34216. I've updated to ticket with a suggestion for a set of > patches > http://rt.cpan.org/Ticket/Display.html?id=34216 And a public "Thanks" to Ron for keeping up the progress! Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark Stosberg Principal Developer ma...@su... Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . . |
|
From: Cees H. <ce...@gm...> - 2008-04-07 01:19:01
|
Nice work Ron! And all the others that submitted patches! Cheers, Cees On Mon, Apr 7, 2008 at 11:34 AM, Ron Savage <ro...@sa...> wrote: > Hi Folks > > Look at this: http://testers.cpan.org/show/CGI-Session.html > > Status since then: > > o RT#34668. I've patched to POD for CGI::Session. Ticked closed > http://rt.cpan.org/Ticket/Display.html?id=34668 > > o RT#32932. Patched in 4.29_1, but not marked off in RT. Ticket closed > http://rt.cpan.org/Ticket/Display.html?id=32932 > > o RT#33635. Patched in 4.29_1, but not marked off in RT. Ticket closed > http://rt.cpan.org/Ticket/Display.html?id=33635 > > o RT#17299. I've patched the POD for CGI::Session. Ticket updated but > left open > http://rt.cpan.org/Ticket/Display.html?id=17299 > > o RT#34216. I've updated to ticket with a suggestion for a set of > patches > http://rt.cpan.org/Ticket/Display.html?id=34216 > > -- > Ron Savage > ro...@sa... > http://savage.net.au/index.html > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Register now and save $200. Hurry, offer ends at 11:59 p.m., > Monday, April 7! Use priority code J8TLD2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Cgi-session-user mailing list > Cgi...@li... > https://lists.sourceforge.net/lists/listinfo/cgi-session-user > |
|
From: Ron S. <ro...@sa...> - 2008-04-07 00:36:33
|
Hi Folks Look at this: http://testers.cpan.org/show/CGI-Session.html Status since then: o RT#34668. I've patched to POD for CGI::Session. Ticked closed http://rt.cpan.org/Ticket/Display.html?id=34668 o RT#32932. Patched in 4.29_1, but not marked off in RT. Ticket closed http://rt.cpan.org/Ticket/Display.html?id=32932 o RT#33635. Patched in 4.29_1, but not marked off in RT. Ticket closed http://rt.cpan.org/Ticket/Display.html?id=33635 o RT#17299. I've patched the POD for CGI::Session. Ticket updated but left open http://rt.cpan.org/Ticket/Display.html?id=17299 o RT#34216. I've updated to ticket with a suggestion for a set of patches http://rt.cpan.org/Ticket/Display.html?id=34216 -- Ron Savage ro...@sa... http://savage.net.au/index.html |
|
From: Ron S. <ro...@sa...> - 2008-03-26 23:29:55
|
Hi Mark > So are we ready for another development release? I could help with > packaging and uploading. Yes. Might as well release a dev immediately. I'm looking forward to test results. > While cpan-testers has been very helpful, so far actually users have > been silent on feedback on the current dev release. This does not surprise me. My personal policy is to never install beta software if I can possibly avoid it, and dev versions of Perl modules fit into that category. -- Ron Savage ro...@sa... http://savage.net.au/index.html |
|
From: Mark S. <ma...@su...> - 2008-03-26 14:37:23
|
Ron Savage wrote:
> Hi Mark
>
>> Adding PL_FILES => {} to Makefile.PL should fix this issue. I've checked
>> in changes (Makefile.PL, Changes). We'll see what the next development
>> release exposes. If old Makefile.PL processing code ignores PL_FILES
>> then I'll rename Build.PL to hide it.
>
> Actually, I looked at the Changes file for ExtUtils::MakeMaker, and
> March 2005 was when PL_FILES was documented, suggesting it was
> implemented before that. So, I'm very tempted to not rename Build.PL at
> all, but to just accept that there will be failures on systems where
> ExtUtils::MakeMaker has not been updated recently. That should not be a
> show-stopper for us.
Thanks for your work on this, Ron.
So are we ready for another development release? I could help with
packaging and uploading.
While cpan-testers has been very helpful, so far actually users have
been silent on feedback on the current dev release.
Mark
|
|
From: Ron S. <ro...@sa...> - 2008-03-26 03:05:24
|
Hi Mark
> Adding PL_FILES => {} to Makefile.PL should fix this issue. I've checked
> in changes (Makefile.PL, Changes). We'll see what the next development
> release exposes. If old Makefile.PL processing code ignores PL_FILES
> then I'll rename Build.PL to hide it.
Actually, I looked at the Changes file for ExtUtils::MakeMaker, and
March 2005 was when PL_FILES was documented, suggesting it was
implemented before that. So, I'm very tempted to not rename Build.PL at
all, but to just accept that there will be failures on systems where
ExtUtils::MakeMaker has not been updated recently. That should not be a
show-stopper for us.
--
Ron Savage
ro...@sa...
http://savage.net.au/index.html
|
|
From: Ron S. <ro...@sa...> - 2008-03-26 02:25:43
|
Hi Mark
> Let's drop Build.PL if it's causing a problem. I personally prefer that
> system over Makefile.PL and agree with advocating it. However,
> Makefile.PL is supported everywhere and is basically here to stay in
> terms of support. I would support trying Build.PL again in the future,
> though.
Adding PL_FILES => {} to Makefile.PL should fix this issue. I've checked
in changes (Makefile.PL, Changes). We'll see what the next development
release exposes. If old Makefile.PL processing code ignores PL_FILES
then I'll rename Build.PL to hide it.
--
Ron Savage
ro...@sa...
http://savage.net.au/index.html
|
|
From: Ron S. <ro...@sa...> - 2008-03-26 00:40:24
|
Hi Mark > Let's drop Build.PL if it's causing a problem. I personally prefer that > system over Makefile.PL and agree with advocating it. However, > Makefile.PL is supported everywhere and is basically here to stay in > terms of support. I would support trying Build.PL again in the future, > though. I've posted a query to the M::B list first, in case it's a known problem. If there's no simple solution, I'll rename Build.PL to Build.PL.todo. > Regarding the UTF8/5.10 issue...from a quick review it sounds like it > might be a Perl 5.10 bug or more generally "not our bug". I would be OK > with marking the test as TODO while 5.10 gets straightened out. Understood. -- Ron Savage ro...@sa... http://savage.net.au/index.html |
|
From: Ron S. <ro...@sa...> - 2008-03-26 00:14:30
|
Hi Puneet > Speaking of which, I just wanted to say thanks to you and Mark > publicly for husbanding this module. One day I will be good enough at > Perl to not just use it but also to embellish it. $many x $thanx; If you want to play with studying the internals, here's an idea: CGI::Session already has the concept of generating ids for sessions. You could investigate how to add support for Data::UUID http://search.cpan.org/~rjbs/Data-UUID-1.148/ to the list of supported id generators. Don't forget the corresponding tests! -- Ron Savage ro...@sa... http://savage.net.au/index.html |
|
From: Mark S. <ma...@su...> - 2008-03-25 15:38:29
|
Ron,
Let's drop Build.PL if it's causing a problem. I personally prefer that
system over Makefile.PL and agree with advocating it. However,
Makefile.PL is supported everywhere and is basically here to stay in
terms of support. I would support trying Build.PL again in the future,
though.
Regarding the UTF8/5.10 issue...from a quick review it sounds like it
might be a Perl 5.10 bug or more generally "not our bug". I would be OK
with marking the test as TODO while 5.10 gets straightened out.
However, I know you've spend more time thinking about this I have, so
I'll defer your final decision about how to handle this.
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark Stosberg Principal Developer
ma...@su... Summersault, LLC
765-939-9301 ext 202 database driven websites
. . . . . http://www.summersault.com/ . . . . . . . .
|
|
From: Mr. P. K. <pu...@ei...> - 2008-03-25 14:24:27
|
On Mar 24, 2008, at 11:28 PM, Ron Savage wrote: > > > Ignore the empty email. It's just Evolution infuriating me again... This is so out of the notebook of intelligent design, I can't stop grinning every time I read it. Speaking of which, I just wanted to say thanks to you and Mark publicly for husbanding this module. One day I will be good enough at Perl to not just use it but also to embellish it. -- Puneet Kishor http://punkish.eidesis.org/ Ph.D. Program, Nelson Institute, UW-Madison http://www.nelson.wisc.edu/ Charter Member, Open Source Geospatial Foundation http://www.osgeo.org/ ----------------------------------------------------------------------- collaborate, communicate, compete ======================================================================= |
|
From: Ron S. <ro...@sa...> - 2008-03-25 04:24:38
|
Hi Mark Ignore the empty email. It's just Evolution infuriating me again... > Would you be able to look at the 4.29_1 test failures? This one appears > to be UTF related. I haven't looked at the others. Looks for utf8 in this: http://use.perl.org/article.pl?sid=08/03/22/1745244&mode=nocomment for interesting info which may explain our curious problems in that area. -- Ron Savage ro...@sa... http://savage.net.au/index.html |
|
From: Ron S. <ro...@sa...> - 2008-03-25 04:22:41
|
Hi Mark > Would you be able to look at the 4.29_1 test failures? This one appears > to be UTF related. I haven't looked at the others. Reading this -- Ron Savage ro...@sa... http://savage.net.au/index.html |
|
From: Ron S. <ro...@sa...> - 2008-03-25 02:14:00
|
Hi Mark > Ron Savage, > > Would you be able to look at the 4.29_1 test failures? This one appears I've renamed t/bug21981.t to t/bug21981.todo. It looks like this test was an idea without sufficient planning to support it. Some versions of Perl don't allow 'use encoding;' by default, and other versions die on sprintf. If (s)printf has to be re-thought, then the problem is far from fixed. > to be UTF related. I haven't looked at the others. Details here: http://testers.cpan.org/show/CGI-Session.html Basically they fall into 2 categories: (1) Illegal seek (2) perl Build.PL Build besides the uft8 problem. Discussion: (1) The Illegal seek seems to only occur in 5.10.0 when DB_File is used (t/api3_db_file.t). I don't get this error with 5.8.8, and the only 5.10.0 I have is Strawberry Perl, which does not ship with DB_File (and on which DB_File cannot be installed because of a missing db.h). The only use of seek in CGI::Session is in CGI::Session::ID::incr, so I'm wondering if tighter code in 5.10.0 is revealling a bug in DB_File. As you can see, I'm guessing. (2) This obviously relates to me adding Build.PL to the mix, although why Build.PL is being run with a Build option is beyond me. On one machine, there was even an extra msg that Module::Build was not installed. It's disappointing, but perhaps Build.PL should be deleted? Thoughts? -- Ron Savage ro...@sa... http://savage.net.au/index.html |
|
From: Ron S. <ro...@sa...> - 2008-03-24 22:50:45
|
Hi Mark > Would you be able to look at the 4.29_1 test failures? This one appears > to be UTF related. I haven't looked at the others. I now think it's time to abandon trying to support utf8-based warnings during testing. I'll rewrite to tests to do something different, and perhaps to even do nothing with utf8. -- Ron Savage ro...@sa... http://savage.net.au/index.html |
|
From: Mark S. <ma...@su...> - 2008-03-24 14:07:39
|
Ron Savage,
Would you be able to look at the 4.29_1 test failures? This one appears
to be UTF related. I haven't looked at the others.
Anyone else is welcome to pitch in, too!
Mark
-------- Original Message --------
Subject: FAIL CGI-Session-4.29_1 MSWin32-x86-multi-thread 5.1
Date: Sat, 22 Mar 2008 16:02:06 -0400
From: DAGOLDEN <dag...@cp...>
To: cpa...@pe...
CC: MAR...@cp...
This distribution has been tested as part of the cpan-testers
effort to test as many new uploads to CPAN as possible. See
http://testers.cpan.org/
Please cc any replies to cpa...@pe... to keep other
test volunteers informed and to prevent any duplicate effort.
--
Dear Mark Stosberg,
This is a computer-generated report for CGI-Session-4.29_1
on perl 5.10.0, created by CPAN-Reporter-1.12.
Thank you for uploading your work to CPAN. However, there was a problem
testing your distribution.
If you think this report is invalid, please consult the CPAN Testers Wiki
for suggestions on how to avoid getting FAIL reports for missing library
or binary dependencies, unsupported operating systems, and so on:
http://cpantest.grango.org/wiki/CPANAuthorNotes
Sections of this report:
* Tester comments
* Program output
* Prerequisites
* Environment and other context
------------------------------
TESTER COMMENTS
------------------------------
Additional comments from tester:
this report is from an automated smoke testing program
and was not reviewed by a human for accuracy
------------------------------
PROGRAM OUTPUT
------------------------------
Output from 'C:\strawberry\perl\bin\perl.exe ./Build test':
t\api3_db_file....................skipped: DB_File not available
t\api3_db_file_freezethaw.........skipped: DB_File not available
t\api3_db_file_storable...........skipped: DB_File not available
t\api3_db_file_storable_incr......skipped: DB_File not available
t\api3_file.......................ok
t\api3_file_freezethaw............skipped: FreezeThaw not available
t\api3_file_freezethaw_incr.......skipped: FreezeThaw not available
t\api3_file_storable..............ok
t\api3_file_storable_incr.........ok
t\api3_incr.......................ok
t\api3_obj_store..................#Using Storable as object serializer
ok
t\api3_obj_store_db_file..........skipped: DB_File is not available
t\bug21952........................ok
t\bug21981........................# Warnings expected. Consult docs re
'utf8'
Can't locate package Encode::Encoding for @Encode::utf8::ISA at (eval
20) line 1.
Can't locate package Encode::Encoding for @Encode::utf8::ISA at (eval
20) line 1.
(in cleanup) Can't locate object method "renewed" via package
"Encode::utf8" (perhaps you forgot to load "Encode::utf8"?) at (eval 20)
line 1.
Can't locate object method "renewed" via package "Encode::utf8" at
C:\strawberry\cpan\build\CGI-Session-4.29_1-3P1RmR\blib\lib/CGI/Session/ErrorHandler.pm
line 45.
# Looks like your test died just after 5.
Dubious, test returned 255 (wstat 65280, 0xff00)
All 5 subtests passed
t\bug24285........................ok
t\cgi_simple......................skipped: CGI::Simple not installed, so
skipping related tests.
t\complex_ds......................ok
t\driver_dbi......................ok
t\expire..........................ok
t\find............................ok
t\flush...........................ok
t\g4..............................ok
t\g4_dbfile.......................skipped: DB_File is NOT available
t\g4_dbfile_freezethaw............skipped: DB_File is NOT available
t\g4_dbfile_storable..............skipped: DB_File is NOT available
t\g4_freezethaw...................skipped: FreezeThaw is NOT available
t\g4_mysql........................skipped: DBD::mysql is NOT available
t\g4_mysql_freezethaw.............skipped: DBD::mysql is NOT available
t\g4_mysql_storable...............skipped: DBD::mysql is NOT available
t\g4_postgresql...................skipped: DataSource is not known
t\g4_postgresql_freezethaw........skipped: DataSource is not known
t\g4_postgresql_storable..........skipped: DataSource is not known
t\g4_sqlite.......................ok
t\g4_sqlite_freezethaw............skipped: FreezeThaw is NOT available
t\g4_sqlite_storable..............ok
t\g4_storable.....................ok
t\header..........................ok
t\ip_matches......................ok
t\is_new..........................ok
t\load............................ok
t\name............................ok
t\parse_dsn.......................ok
t\remote_addr.....................ok
t\str2seconds.....................ok
t\symlink_db_file.................skipped: DB_File not available
t\symlink_file....................skipped: Your OS doesn't support symlinks
Test Summary Report
-------------------
t\bug21981.t (Wstat: 65280 Tests: 5 Failed: 0)
Non-zero exit status: 255
Files=46, Tests=584, 39 wallclock secs ( 0.09 usr + 0.55 sys = 0.64 CPU)
Result: FAIL
Failed 1/46 test programs. 0/584 subtests failed.
------------------------------
PREREQUISITES
------------------------------
Prerequisite modules loaded:
requires:
Module Need Have
------------ ---- --------
Data::Dumper 0 2.121_14
Digest::MD5 0 2.36_01
Scalar::Util 0 1.19
build_requires:
Module Need Have
------------ ---- --------
Test::More 0 0.74
Test::Pod 0 1.26
------------------------------
ENVIRONMENT AND OTHER CONTEXT
------------------------------
Environment variables:
AUTOMATED_TESTING = 1
COMSPEC = C:\WINDOWS\system32\cmd.exe
INCLUDE = ;C:\strawberry\c\include;C:\strawberry\perl\lib\CORE
LIB = ;C:\strawberry\c\lib;C:\strawberry\perl\bin
NUMBER_OF_PROCESSORS = 1
PATH =
C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\bin;C:\strawberry\c\bin;C:\strawberry\perl\bin
PERL5LIB =
C:\strawberry\cpan\build\Test-Pod-1.26-iNDgJg/blib/arch;C:\strawberry\cpan\build\Test-Pod-1.26-iNDgJg/blib/lib
PERL5_CPANPLUS_IS_RUNNING = 876
PERL5_CPAN_IS_RUNNING = 876
PERL5_CPAN_IS_RUNNING_IN_RECURSION = 1632,876
PERL_CR_SMOKER_CURRENT = CGI-Session-4.29_1
PERL_MM_USE_DEFAULT = 1
PROCESSOR_IDENTIFIER = x86 Family 6 Model 15 Stepping 6, GenuineIntel
TEMP = C:\DOCUME~1\David\LOCALS~1\Temp
TERM = dumb
Perl special variables (and OS-specific diagnostics, for MSWin32):
$^X = C:\strawberry\perl\bin\perl.exe
$UID/$EUID = 0 / 0
$GID = 0
$EGID = 0
Win32::GetOSName = WinXP/.Net
Win32::GetOSVersion = Service Pack 2, 5, 1, 2600, 2, 2, 0, 768, 1
Win32::FsType = FAT32
Win32::IsAdminUser = 1
Perl module toolchain versions installed:
Module Have
------------------- ---------
CPAN 1.92_57
Cwd 3.2701
ExtUtils::CBuilder 0.21
ExtUtils::Command 1.13
ExtUtils::Install 1.44
ExtUtils::MakeMaker 6.42
ExtUtils::Manifest 1.51_01
ExtUtils::ParseXS 2.18_02
File::Spec 3.2701
Module::Build 0.2808_01
Module::Signature n/a
Test::Harness 3.09
Test::More 0.74
YAML 0.66
YAML::Syck 1.04
version 0.74
--
Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
Platform:
osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags =' -s -O2 -DWIN32 -DHAVE_DES_FCRYPT
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing
-DPERL_MSVCRT_READFIX',
optimize='-s -O2',
cppflags='-DWIN32'
ccversion='', gccversion='3.4.5', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='long
long', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='g++', ldflags ='-s -L"C:\strawberry\perl\lib\CORE"
-L"C:\strawberry\c\lib"'
libpth=C:\strawberry\c\lib
libs= -lmsvcrt -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool
-lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid
-lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32
perllibs= -lmsvcrt -lmoldname -lkernel32 -luser32 -lgdi32
-lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32
-luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32
libc=-lmsvcrt, so=dll, useshrplib=true, libperl=libperl510.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-mdll -s -L"C:\strawberry\perl\lib\CORE"
-L"C:\strawberry\c\lib"'
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark Stosberg Principal Developer
ma...@su... Summersault, LLC
765-939-9301 ext 202 database driven websites
. . . . . http://www.summersault.com/ . . . . . . . .
|
|
From: Mark S. <ma...@su...> - 2008-03-21 19:14:29
|
There is now a patch available which makes our cookie generation more RFC-compliant and should fix the issue reported with Safari: http://rt.cpan.org/Ticket/Display.html?id=34216#txn-438169 Note that it makes use of the "max_age" method added in CGI.pm around 2.8x. We don't currently require any version of CGI.pm, but perhaps we could. Related to this, CGI::Simple would have supported the old "expires" interface, but it does *not* yet support the "max_age" feature. So the fix for better RFC compliance may break for those using CGI::Simple. A separate bug has been filed to fix CGI::Simple. If someone wanted to quickly generate a patch for improving CGI::Simple in this way, we could possibly wait for that to ease the transition. http://rt.cpan.org/Ticket/Display.html?id=34310 Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark Stosberg Principal Developer ma...@su... Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . . |
|
From: Mark S. <ma...@su...> - 2008-03-21 15:30:50
|
> o Digression: Line 93 of CGI::Cookie is: > s/\s*(.*?)\s*/$1/; > whereas line 34 of CGI::Simple::Cookie is: > $pair =~ s/^\s+|\s+$//; # trim leading trailing whitespace > You can see there's a missing /g on this last line, since it removes > either leading or trailing spaces, but not both. I'll log a bug report. Great catch, Ron! > Whose responsibility is it to ensure only cookies for the 'current' > domain are retrieved from the headers sent by the client? I suppose the > client should only be sending 'relevant' cookies. Perhaps in OP's > situation, both cookies are relevant? I did the Perlmonks.org test of logging in both with and without the "www" and then checking the cookies set when I visit "www". Two cookies are sent. Firefox sent "perlmonks.org" first, and then "www.perlmonks.org" second. I also read the Cookie RFC to see if there is a "right" order to send and parse cookies in, and it appears there is not. Therefore, I think this is not a bug at all, but the user's burden to check the domain in this case and make sure they have the right cookie. Mark |
|
From: Mr. P. K. <pu...@ei...> - 2008-03-21 03:27:14
|
On Mar 20, 2008, at 10:24 PM, Ron Savage wrote: > Hi Mark > >> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=34280 > >> I have 2 different sites: site.com and sub.site.com both using >> CGI::Session >> When I go to sub.site.com there are 2 session cookies are being sent, >> first with Host: .site.com and second with Host: sub.site.com >> The problem is CGI::Session use first cookie, which isn't valid for >> sub.site.com, thus creating new session each time you hit >> sub.site.com >> On Mar 20, 2008, at 10:50 AM, Puneet Kishor wrote: > Is this really a bug? As far as I understand, site.com and > sub.site.com are two totally different sites, with two separate DNS > entries and everything. You can configure your webserver to redirect > from one to the other, but they are two. > > Don't believe me? Go to www.perlmonks.org and log in with your > account. > Open another browser windows and go to perlmonks.org and see that you > are *not* logged in. On Mar 20, 2008, at 11:08 AM, Mark Stosberg wrote: > I believe it's correct that two cookies would get set back. I'm > surprised that the sub-domain cookie isn't checked first. > > I think the best course of action would be to review the RFC about > cookies to confirm how they should be distributed and checked. > > In any case, I agree there's a good chance it's not a bug in > CGI::Session, but it would still be nice to point the fellow in the > right direction if we can. > > Mark > > Here's what I think happens, using CGI::Session V 4.21-to-be from SVN > and CGI V 3.34 and CGI::Cookie 1.28. > > o We hit lines 735 .. 737 of CGI::Session: > eval { > $self->{_CLAIMED_ID} = $query->cookie( $self->name ) || > $query->param( $self->name ); > }; > > o We then hit lines 2765 in CGI (within sub cookie): > unless ( defined($value) ) { > $self->{'.cookies'} = CGI::Cookie->fetch [Note 1] > unless $self->{'.cookies'}; > > o We then hit line 43 in CGI::Cookie (within sub fetch): > return $class->parse($raw_cookie); > > o We then hit lines 109 .. 110 in CGI::Cookie (within sub parse): > return \%results unless wantarray; > return %results; > [Note 1] We don't want an array, so we return a hash ref. > > o Digression: Line 93 of CGI::Cookie is: > s/\s*(.*?)\s*/$1/; > whereas line 34 of CGI::Simple::Cookie is: > $pair =~ s/^\s+|\s+$//; # trim leading trailing whitespace > You can see there's a missing /g on this last line, since it removes > either leading or trailing spaces, but not both. I'll log a bug > report. > We return you now to your regular scheduled bulletin (built-in?)... > > o Back in CGI, line 2773, we have: > return $self->{'.cookies'}->{$name}->value if defined($name) && $name > ne ''; > since we passed a name in at line 736 of CGI::Session (first dot > point). > > But at this point CGI does not check the domain, because it does not > care... > > That suggests to me the problem is actually in CGI::Cookie's sub > parse, > line 107: > $results{$key} ||= $self->new(-name=>$key,-value=>\@values); > where cookies are stored by name without any regard as to their > domain. > > Whose responsibility is it to ensure only cookies for the 'current' > domain are retrieved from the headers sent by the client? I suppose > the > client should only be sending 'relevant' cookies. Perhaps in OP's > situation, both cookies are relevant? > > -- > Ron Savage > ro...@sa... > http://savage.net.au/index.html |
|
From: Ron S. <ro...@sa...> - 2008-03-21 03:20:41
|
Hi Mark > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=34280 > > I have 2 different sites: site.com and sub.site.com both using CGI::Session > When I go to sub.site.com there are 2 session cookies are being sent, > first with Host: .site.com and second with Host: sub.site.com > The problem is CGI::Session use first cookie, which isn't valid for > sub.site.com, thus creating new session each time you hit sub.site.com Here's what I think happens, using CGI::Session V 4.21-to-be from SVN and CGI V 3.34 and CGI::Cookie 1.28. o We hit lines 735 .. 737 of CGI::Session: eval { $self->{_CLAIMED_ID} = $query->cookie( $self->name ) || $query->param( $self->name ); }; o We then hit lines 2765 in CGI (within sub cookie): unless ( defined($value) ) { $self->{'.cookies'} = CGI::Cookie->fetch [Note 1] unless $self->{'.cookies'}; o We then hit line 43 in CGI::Cookie (within sub fetch): return $class->parse($raw_cookie); o We then hit lines 109 .. 110 in CGI::Cookie (within sub parse): return \%results unless wantarray; return %results; [Note 1] We don't want an array, so we return a hash ref. o Digression: Line 93 of CGI::Cookie is: s/\s*(.*?)\s*/$1/; whereas line 34 of CGI::Simple::Cookie is: $pair =~ s/^\s+|\s+$//; # trim leading trailing whitespace You can see there's a missing /g on this last line, since it removes either leading or trailing spaces, but not both. I'll log a bug report. We return you now to your regular scheduled bulletin (built-in?)... o Back in CGI, line 2773, we have: return $self->{'.cookies'}->{$name}->value if defined($name) && $name ne ''; since we passed a name in at line 736 of CGI::Session (first dot point). But at this point CGI does not check the domain, because it does not care... That suggests to me the problem is actually in CGI::Cookie's sub parse, line 107: $results{$key} ||= $self->new(-name=>$key,-value=>\@values); where cookies are stored by name without any regard as to their domain. Whose responsibility is it to ensure only cookies for the 'current' domain are retrieved from the headers sent by the client? I suppose the client should only be sending 'relevant' cookies. Perhaps in OP's situation, both cookies are relevant? -- Ron Savage ro...@sa... http://savage.net.au/index.html |
|
From: Mark S. <ma...@su...> - 2008-03-20 15:24:43
|
Here's a new bug report on CGI::Session if anyone wants to help with it.
Mark
-------- Original Message --------
Subject: [rt.cpan.org #34280] Incorrect session ID for subdomain
Date: Thu, 20 Mar 2008 07:48:36 -0400
From: Тимур Кондратьев via RT <bug...@rt...>
Reply-To: bug...@rt...
To: undisclosed-recipients:;
References: <RT-...@rt...> <47E...@ad...>
Thu Mar 20 07:48:34 2008: Request 34280 was acted upon.
Transaction: Ticket created by ma...@ad...
Queue: CGI-Session
Subject: Incorrect session ID for subdomain
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ma...@ad...
Status: new
Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=34280 >
Hello.
I have 2 different sites: site.com and sub.site.com both using CGI::Session
When I go to sub.site.com there are 2 session cookies are being sent,
first with Host: .site.com and second with Host: sub.site.com
The problem is CGI::Session use first cookie, which isn't valid for
sub.site.com, thus creating new session each time you hit sub.site.com
Changing $CGI::Session::NAME is not the option cause both sites run on
same server under mod_perl persistent environment.
Versions:
# $Id: Session.pm 353 2006-12-05 02:10:19Z markstos $
$CGI::Session::VERSION 4.20
This is perl, v5.8.8 built for i386-freebsd-64int
Thank you.
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark Stosberg Principal Developer
ma...@su... Summersault, LLC
765-939-9301 ext 202 database driven websites
. . . . . http://www.summersault.com/ . . . . . . . .
|
|
From: Mark S. <ma...@su...> - 2008-03-19 19:28:05
|
See the discussion in this bug report for a description of when expiration dates for cookies might not work as you'd expect, and some suggestions on how to fix it: http://rt.cpan.org/Ticket/Display.html?id=34216 I have asked the poster to develop a patch, but since it will affect other users, one of you may also be interested in helping with this issue. I expect a new release with many bug fixes to come out soon, thanks to Ron Savage and others. I'm mainly waiting on SVN access now so that I can commit a patch with the final version bumps and then upload the release. However, this bug fix could also make it into the release. Mark |
|
From: Ron S. <ro...@sa...> - 2008-03-16 05:44:13
|
Hi Mark > One of the msgs via CPAN has given me an idea. I'll change the text Of course that should read RT not CPAN. > Also, I'll copy to CPAN the rationale I gave on the list for leaving > utf8-related warnings visible. And that one too should read RT. -- Ron Savage ro...@sa... http://savage.net.au/index.html |
|
From: Ron S. <ro...@sa...> - 2008-03-16 05:24:42
|
Hi Mark On Sun, 2008-03-16 at 00:23 -0400, Mark Stosberg wrote: > I have now reviewed the "diffs" of all of Ron's commits for this round of > bugfixing, and they all look good. Thanks, Ron! Progress! > Currently I'm waiting on renewed "commit" access myself, and then I plan OK. > to publish a 4.29_1 release with Ron's changes, for wider testing. Just curious - Why the jump from 4.20 to 4.30 and not 4.21. Is it the quantity of fixes applied? I assume so. > After about a week (assuming nothing unexpected comes up), I think it > would be appropriate to release 4.30 then. OK. One of the msgs via CPAN has given me an idea. I'll change the text associated with the utf8 tests to say something like (after the current text): Warnings expected. Consult docs re 'utf8' That should make it clearer. Also, I'll copy to CPAN the rationale I gave on the list for leaving utf8-related warnings visible. Also, just for the record, there are still 2 bugs on CPAN which I have fixed: 32932 and 33635. -- Ron Savage ro...@sa... http://savage.net.au/index.html |
142 messages has been excluded from this view by a project administrator.
