RE: possible buget in CGI.pm
> From: mike808 [mailto:[EMAIL PROTECTED]] > Sent: 24 July 2002 05:54 > To: Lincoln Stein; Cope, Greg; [EMAIL PROTECTED] > Subject: Re: possible buget in CGI.pm > > Lincoln, Greg, mod_perl list: > > The problem appears to be that the -no_xhtml option is only > processed in > _setup_symbols. This is called only during import() and > compile(), and sets $XHTML appropriately. > > However, $XHTML is reset to 1 in initialize_globals(). > _reset_globals() is an > alias for this as well. initialize_globals() is called only > once in the > startup execution (has a comment "Make mod_perl happy") of > the module. > > However, _reset_globals is called during new(), and is > registered with > mod_perl as a cleanup handler. > > What this means is that after the first execution, the > cleanup handler fires > and _reset_globals() is called, which calls > initialize_globals(), which then > sets the global $XHTML to 1. QED. Hi Mike, Thanks for the reply, we had got to a similar point as well (that initialize globals was stomping on it the second time round), but not is as much detail thanks for the explinatoin! Lincon, is this enough to go on? We've munged our install, which is not the ideal solution. Thanks everyone for thier time. Lincon for the module, and Mike for the excellent explinatoin. The list is great, and support like this is an excellent factor in our internal push for more Open Source stuff! Greg This message and any attachment has been virus checked by Pfizer Corporate Information Technology, Sandwich.
Re: possible buget in CGI.pm
> On Tuesday 23 July 2002 08:27 am, [EMAIL PROTECTED] wrote: > > We do not want CGI.pm to return XHTML ... > > So in Apache::Registry executed scripts we use: > > use CGI qw( -no_xhtml ); > > But on the first invocation it returns normal HTML. On second invocation > > it ignores this directive and returns XHTML. We started a dev server > > with -X to confirm this. It would appear CGI resets its globals > > somewhere. ... > > Some versions: Apache 1.3.26, perl 5.6.1, mod_perl 1.27, CGI 2.81 On Tuesday 23 July 2002 12:47 pm, Lincoln Stein wrote: > I'm aware of the problem, but I haven't been able to track it down. Any > help is welcome. Lincoln, Greg, mod_perl list: The problem appears to be that the -no_xhtml option is only processed in _setup_symbols. This is called only during import() and compile(), and sets $XHTML appropriately. However, $XHTML is reset to 1 in initialize_globals(). _reset_globals() is an alias for this as well. initialize_globals() is called only once in the startup execution (has a comment "Make mod_perl happy") of the module. However, _reset_globals is called during new(), and is registered with mod_perl as a cleanup handler. What this means is that after the first execution, the cleanup handler fires and _reset_globals() is called, which calls initialize_globals(), which then sets the global $XHTML to 1. QED. It looks like -nosticky suffers from the same fate as well, and I would venture to guess that all of the variables reset in initialize_globals() are not being set properly according to the values parsed in _setup_symbols(). e.g. $NPH, $NOSTICKY, $DEBUG, $HEADERS_ONCE, etc. I think the 'undef $NPH' in new() was an attempt to address this for that variable. But it still leaves the rest out in the cold. Because _setup_symbols eats the parameters (the options passed in on the 'use' line), there's no way to call it again later in new() since it ran at compile time. One might "preserve" the options passed in to _setup_symbols() and then have new() call it again with those options to make sure that the new instance retains the options set on the 'use' line. LDS, You might want to separate the option parsing from the autoload magic in _setup_symbols(), and just call the option parsing part with the saved options from the 'use' line in the cleanup handler. Mike808/ -- () Join the ASCII ribbon campaign against HTML email and Microsoft-specific /\ attachments. If I wanted to read HTML, I would have visited your website! Support open standards.
Re: possible buget in CGI.pm
I'm aware of the problem, but I haven't been able to track it down. Any help is welcome. Lincoln On Tuesday 23 July 2002 08:27 am, [EMAIL PROTECTED] wrote: > Hi All, > > We are implementing mod_perl here for internal intranet use. We have > discovered a possible buglet in CGI.pm. > > We do not want CGI.pm to return XHTML as it upsets Verity indexing (long > story). > > So in Apache::Registry executed scripts we use: > > use CGI qw( -no_xhtml ); > > But on the first invocation it returns normal HTML. On second invocation > it ignores this directive and returns XHTML. We started a dev server with > -X to confirm this. It would appear CGI resets its globals somewhere. > > Can someone confirm this? > > Also is this the right forum for this ? > > Which bit of the plot have I missed? > > Some versions: Apache 1.3.26, perl 5.6.1, mod_perl 1.27, CGI 2.81 > > Thanks, > > Greg Cope > > > > This message and any attachment has been virus checked by > Pfizer Corporate Information Technology, Sandwich. >
RE: possible buget in CGI.pm
> -Original Message-
> From: darren chamberlain [mailto:[EMAIL PROTECTED]]
> > Can someone confirm this?
>
> Yes:
>
Good I'm not mad :-)
> From CGI.pm, version 2.81:
>
> 35 # > Here are some globals that you might want to
> adjust <<
> 36 sub initialize_globals {
> 37 # Set this to 1 to enable copious autoloader
> debugging messages
> 38 $AUTOLOAD_DEBUG = 0;
> 39
> 40 # Set this to 1 to generate XTML-compatible output
> >> 41 $XHTML = 1;
> 42
> 43 # Change this to the preferred DTD to print in
> start_html()
> 44 # or use default_dtd('text of DTD to use');
> 45 $DEFAULT_DTD = [ '-//W3C//DTD HTML 4.01 Transitional//EN',
> 46
>'http://www.w3.org/TR/html4/loose.dtd' ] ;
> 47
>
>Judging from line 35 you might want to adjust some of those globals.
>
>If you are using CGI in the OO way, you can just subclass CGI:
>
> package My::CGI;
>
> use base qw(CGI);
> sub initialize_globals {
> CGI::initialize_globals();
> $CGI::XHTML = 0;
> }
>
>And then:
>
> my $q = My::CGI->new;
>
>Of course, I haven't tested this.
>
>Another option is to call:
>
> CGI->import("-no_xhtml");
>
>at the top of your Registry script, which will be executed every time,
>whereas the "use CGI qw( -no_xhtml );" is only being called at compile
>time.
Lookout has givenup putting the '>'s in!. grh
Thanks for those Darren,
With out wishing to be rude, the above are all workarrounds the bug (ie it
should not overide the -no_xhtml pragma), and we've used our own.
The subclssing one was good thou! and I did not know the CGI->import one.
Thanks,
Greg
(darren)
--
You can put a man through school, but you cannot make him think.
-- Ben Harper
This message and any attachment has been virus checked by
Pfizer Corporate Information Technology, Sandwich.
Re: possible buget in CGI.pm
Hi,
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2002-07-23 11:26]:
> We are implementing mod_perl here for internal intranet use. We have
> discovered a possible buglet in CGI.pm.
>
> We do not want CGI.pm to return XHTML as it upsets Verity indexing
> (long story).
So sorry to hear about that.
> So in Apache::Registry executed scripts we use:
>
> use CGI qw( -no_xhtml );
>
> But on the first invocation it returns normal HTML. On second
> invocation it ignores this directive and returns XHTML. We started a
> dev server with -X to confirm this. It would appear CGI resets its
> globals somewhere.
>
> Can someone confirm this?
Yes:
From CGI.pm, version 2.81:
35 # > Here are some globals that you might want to adjust <<
36 sub initialize_globals {
37 # Set this to 1 to enable copious autoloader debugging messages
38 $AUTOLOAD_DEBUG = 0;
39
40 # Set this to 1 to generate XTML-compatible output
>> 41 $XHTML = 1;
42
43 # Change this to the preferred DTD to print in start_html()
44 # or use default_dtd('text of DTD to use');
45 $DEFAULT_DTD = [ '-//W3C//DTD HTML 4.01 Transitional//EN',
46 'http://www.w3.org/TR/html4/loose.dtd' ] ;
47
Judging from line 35 you might want to adjust some of those globals.
If you are using CGI in the OO way, you can just subclass CGI:
package My::CGI;
use base qw(CGI);
sub initialize_globals {
CGI::initialize_globals();
$CGI::XHTML = 0;
}
And then:
my $q = My::CGI->new;
Of course, I haven't tested this.
Another option is to call:
CGI->import("-no_xhtml");
at the top of your Registry script, which will be executed every time,
whereas the "use CGI qw( -no_xhtml );" is only being called at compile
time.
(darren)
--
You can put a man through school, but you cannot make him think.
-- Ben Harper
possible buget in CGI.pm
Hi All, We are implementing mod_perl here for internal intranet use. We have discovered a possible buglet in CGI.pm. We do not want CGI.pm to return XHTML as it upsets Verity indexing (long story). So in Apache::Registry executed scripts we use: use CGI qw( -no_xhtml ); But on the first invocation it returns normal HTML. On second invocation it ignores this directive and returns XHTML. We started a dev server with -X to confirm this. It would appear CGI resets its globals somewhere. Can someone confirm this? Also is this the right forum for this ? Which bit of the plot have I missed? Some versions: Apache 1.3.26, perl 5.6.1, mod_perl 1.27, CGI 2.81 Thanks, Greg Cope This message and any attachment has been virus checked by Pfizer Corporate Information Technology, Sandwich.
