Re: PerlSendHeader
Thanks, Tom. Yep, this does the job just fine and allows me to send
the Content-type later:
print "HTTP/1.1 OK\n";
Is ignoring PerlSendHeader considered a feature? ;)
-gm
On Tue, 20 Nov 2001, Tom Mornini wrote:
> This took me a LONG time to deal with when I was new to mod_perl...
>
> Apache::Registry tries to be smart regardless of PerlSendHeader.
>
> If it doesn't see "HTTP/1.x OK" first, out come the headers.
>
> Two options:
> $r->response(200);
> $r->send_http_header('text/html')
>
> or print the HTTP line...
>
> On Tuesday, November 20, 2001, at 04:17 PM, Gregor Mosheh wrote:
>
> >
> > I need mod_perl to not send the Content-type header when a program is
> > run. Despite the "Off" value of the "PerlSendHeader" variable in
> > httpd.conf, the header is still being sent.
> >
> > This test program still sends an extraneous Content-type header:
> >print "Content-type: text/html\n\n";
> >print "Hello World\n";
> >
> > Here's the relevant portion of the httpd.conf:
> > # mod_perl initialization
> > PerlRequire /usr/local/apache-dev/ultraform-lib/startup.pl
> > PerlModule Apache::DBI DBD::mysql
> > #PerlSetEnv key value
> > PerlTaintCheck Off
> > PerlWarn On
> > PerlFreshRestart On
> > PerlSetVar UndefOnReload On
> > PerlSendHeader Off
> >
> > AllowOverride None
> > Options ExecCGI
> > Order allow,deny
> > Allow from all
> > SetHandler perl-script
> > PerlHandler Apache::Registry
> > PerlSendHeader Off
> >
> >
> >
> >
> > --
> > Gregor Mosheh, B.S. http://www.blackangel.net/
> >
> >As we enjoy great advantages from inventions of others, we
> >should be glad of an opportunity to serve others by any
> >invention of ours; and this we should do freely and generously.
> > -- Benjamin Franklin
> >
> >
> >
> --
> -- Tom Mornini
> -- InfoMania Printing & Prepress
>
--
Gregor Mosheh, B.S. http://www.blackangel.net/
As we enjoy great advantages from inventions of others, we
should be glad of an opportunity to serve others by any
invention of ours; and this we should do freely and generously.
-- Benjamin Franklin
[OT] Re: How to create a browser popup window
On Tue, 20 Nov 2001, Rob Bloodgood wrote:
> > You must include code to deal with the fact that you may have already
> > opened a popup window. Something like this:
>
> That is simply not true. window.open() with a named window ('popupwin', in
> your example) ALWAYS reuses that window, on every browser I've ever been
> able to test.
I didn't say duplicate windows was the problem. The problems are:
1) If the window exists it may have lost focus.
2) If the window exists you cannot resize it (eg for displaying full-size
images from thumbnails, etc.)
> A corrected version of your sample script follows. It's much simpler now...
So simple it only does half of what it did :)
?
- nick
PerlSendHeader
I need mod_perl to not send the Content-type header when a program is run. Despite the "Off" value of the "PerlSendHeader" variable in httpd.conf, the header is still being sent. This test program still sends an extraneous Content-type header: print "Content-type: text/html\n\n"; print "Hello World\n"; Here's the relevant portion of the httpd.conf: # mod_perl initialization PerlRequire /usr/local/apache-dev/ultraform-lib/startup.pl PerlModule Apache::DBI DBD::mysql #PerlSetEnv key value PerlTaintCheck Off PerlWarn On PerlFreshRestart On PerlSetVar UndefOnReload On PerlSendHeader Off AllowOverride None Options ExecCGI Order allow,deny Allow from all SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader Off -- Gregor Mosheh, B.S. http://www.blackangel.net/ As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. -- Benjamin Franklin
Re: Documentation patch for mod_perl//win32
On Tue, 20 Nov 2001, Alessandro Forghieri wrote: > Greetings. > > [...] > > > This documentation patch addresses the single thread snafu on Win32. > > > Comments, corrections and additions (even subtractions) > > >welcome. (Also on the hot topic of the day: where in the doc does this > fit?) > > > > Nice, but please repost it inlined. Otherwise people won't be able to > > comment on your words. > [...] > > hhh I see - attachment stripping. So here it comes - brace. That's great that you thought this out and put it together; a few comments below appear below ... > > -SNIP---SNIP---SNIP---(sigh, the good ole days) > > > =head1 OS caveats: multithreading on Windows NT > > =head2 The problem > > mod_Perl's multithreading capability is severely limited on Win32 > platforms (WinNT and Win2K). It is in fact limited to the point of > non-existence: mod_perl on Win32 is single threaded. A single instance > of the interpreter is created, and it is protected with a server-wide > lock, that prevents more than one thread to be using the interpreter > at any one time. > > It is actually a little worse than that, as not only does the > interpreter lock prevents parallel processing of perl requests, it > also prevents B request to proceed (yes, this means that static > content requests will also be blocked). > > This rather unfortunate situation is supposed to change when Apache > 2.0 and mod_perl 2.0 will be officially released: in the 2 series, > with full multithreading support, apache will be managing an > interpreter pool whose dimensions (among other parameter) will be > tunable, as documented in http://perl.apache.org/~dougm/modperl_2.0.html The above, and a couple places below, come off to me as being quite down on Win32 mod_perl, especially as an introduction. Although in general one shouldn't generalize, I think it's fair to say that many mod_perl Win32 users use it for exploration and/or development, and this intro might raise needless concern. What about the following: =head2 The problem On Win32, mod_perl is effectively single threaded. What this means is that a single instance of the interpreter is created, and this is then protected by a server-wide lock that prevents more than one thread from using the interpreter at any one time. The fact that this will prevent parallel processing of requests, including static requests, can have serious implications for production servers that often must handle concurrent or long-running requests. This situation will change with Apache/mod_perl 2.0, which is based on a multi-process/multi-thread approach using a native Win32 threads implementation. See http://perl.apache.org/~dougm/modperl_2.0.html for details. > The 2.0 release is still some time away unfortunately, which means > that users of 1.3.x are stuck in single threaded world. For those affected, it's probably a good idea to be a bit more specific; how about *** At the time of writing, Apache-2.0 is in a beta stage of development. mod_perl-2.0 is being actively developed, including the Win32 port; if you would like a preview and/or would like to contribute to the development process, see the documents on obtaining mod_perl-2.0 by cvs. *** > > =head2 Does it really matter? > > How serious is this? For some people and application classes it may be a > non-problem, assuming the static material issue is handled differently. It's also not a problem for low traffic sites and for people using Win32 for single-user development ... > > If your application is CPU bound, and all requests take roughly the > same time to complete, then having more processing thread than > processors (CPUs) will actually slow things down, because of the > context switching overhead. Note that even in this case, the current > state of mod_perl will bar owners of multiprocessor Win32 machines > from gaining a load balancing advantage from their superior hardware. > > On the other hand, applications dealing with a large service times > spread - say ranging from fractions of a second to a minute and above > - stand to lose a great deal of responsiveness from being single > threaded. The reason is that short requests that happen to be queued > after long ones will be delayed for the entire duration of the "jobs" > that precede them in the queue; with multitasking they would get a chance > to complete much earlier. > > As a real life example, think a manufacturing application where, most > of the time, users are navigating a Bill Of Material - a hierarchical > structure. The requests generated by this usage pattern have a rather > short service time, when moving from a component (node) of the BOM to > one of its children or siblings. Now and then, however, a new Bill Of > Ma
Re: PerlModule not updating %INC
At 18.32 -0500 11/20/2001, Robert Landrum wrote: >> >If that is the case, My::Special::Module won't be loaded and compiled until the >very first time that someone hits /whatever. >> >>Just about EVERY module we use has a 'PerlModule' call to it, outside any enclosing >blocks. Although I do have 'PerlHandler' directives in and >blocks, the modules they use are preloaded prior to the enclosing block. We're hip >to shared memory :-) > >It just hit me That is why Apache::StatINC isn't working. > >We use Apache::StatINC on our development server, but we never preload any modules... > We just use > > >SetHandler perl-script >PerlHandler My::Special::Module > > >and Apache::StatINC works. > >If you preload, It's not going to put the module into %INC. Otherwise Apache::StatINC >would intentionally overwrite that shared memory and destroy the purpose for using >PerlModule in the first place. If this is true, it is a change from prior behavior. (And a bit distressing.) I for one would not complain of Apache::StatINC dirtying memory pages -- I'm really only concerned with shared memory on a production server, and I wouldn't run StatINC outside of the development environment. Besides, I'm assuming that if I do my trick of calling 'use' in a block (which DOES update %INC) that the module code pages are still shared. What is more distressing though is that StatINC may not be the only consumer of %INC. (e.g., Apache::Status does not report these modules in "Loaded Modules") The real trouble is that it is deviating from Doing the Right Thing by perl. >I could be wrong... but I think that the answer is that "It's not a bug, it's a >feature", and that the behavior is actually correct. > For the above reasons, I hope you are wrong. :-) But you may be right! David
Re: PerlModule not updating %INC
> If you preload, It's not going to put the module into %INC. > Otherwise Apache::StatINC would intentionally overwrite that shared > memory and destroy the purpose for using PerlModule in the first > place. ...and that's why you shouldn't use StatINC on a production server. There is no magic about pre-loading: %INC should be set and StatINC will overwrite it if you change the file, ruining your shared memory. It sounds like this is a real bug with PerlModule. This was supposed to be fixed by 1.26, but I guess the fix didn't work or it got broken again. (Doug?) - Perrin
Re: PerlModule not updating %INC
> > >If that is the case, My::Special::Module won't be loaded and >compiled until the very first time that someone hits /whatever. > >Just about EVERY module we use has a 'PerlModule' call to it, >outside any enclosing blocks. Although I do have 'PerlHandler' >directives in and blocks, the modules they use >are preloaded prior to the enclosing block. We're hip to shared >memory :-) It just hit me That is why Apache::StatINC isn't working. We use Apache::StatINC on our development server, but we never preload any modules... We just use SetHandler perl-script PerlHandler My::Special::Module and Apache::StatINC works. If you preload, It's not going to put the module into %INC. Otherwise Apache::StatINC would intentionally overwrite that shared memory and destroy the purpose for using PerlModule in the first place. I could be wrong... but I think that the answer is that "It's not a bug, it's a feature", and that the behavior is actually correct. Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: PerlModule not updating %INC
At 18.02 -0500 11/20/2001, Robert Landrum wrote: >At 2:31 PM -0800 11/20/01, David Pisoni wrote: >> >We have been doing development using mod_perl, but finding that Apache::StatINC >was not working as expected (i.e., we needed to restart the web server in order to >see our module changes in effect.) Our apache config files preload all necessary >modules at start time using the 'PerlModule' directive. When I started peeking >through Apache::Status I found that although all of our loaded modules appear in the >"Inheritance Tree" and the "ISA Tree", most of them did not appear in the "Loaded >Modules" section. (I also did a test handler with a dump of the contents of %INC, >and said modules were missing.) The only modules of ours which DID appear were those >which were ALSO called for with 'use' calls by other modules. >>> >> > > >I just reread your original post... I think I may know what the problem is (maybe). >Are you using handlers? > > >SetHandler perl-script >PerlModule My::Special::Module >PerlHandler My::Special::Module > > > >If that is the case, My::Special::Module won't be loaded and compiled until the very >first time that someone hits /whatever. Just about EVERY module we use has a 'PerlModule' call to it, outside any enclosing blocks. Although I do have 'PerlHandler' directives in and blocks, the modules they use are preloaded prior to the enclosing block. We're hip to shared memory :-) >This explains the missing modules in %INC (I think), but it does not explain the >problem with Apache::StatINC. > >> >Out of curiosity, I took our configuration file and changed all the 'PerlModule' >directives to 'use' calls (inside a block), and lo and behold, they all >appeared in %INC. >>> >> > >And did this fix your problem with Apache::StatINC too? > >Rob > Yes. StatINC indeed uses %INC to do its magic. StatINC's success or failure in this situation is merely a symptom though, not the real problem. We could simply set our configuration files as I've described here, but I'm interested in mod_perl working correctly for everyone, hence I continue to beat this drum. :-) I don't assume that the problem is unique to us -- rather I assume that we're the only ones experiencing it who both realize it and are doing something about it. Thanks, David
Re: PerlModule not updating %INC
At 2:31 PM -0800 11/20/01, David Pisoni wrote: > >We have been doing development using mod_perl, but finding that >Apache::StatINC was not working as expected (i.e., we needed to >restart the web server in order to see our module changes in >effect.) Our apache config files preload all necessary modules at >start time using the 'PerlModule' directive. When I started peeking >through Apache::Status I found that although all of our loaded >modules appear in the "Inheritance Tree" and the "ISA Tree", most of >them did not appear in the "Loaded Modules" section. (I also did a >test handler with a dump of the contents of %INC, and said modules >were missing.) The only modules of ours which DID appear were those >which were ALSO called for with 'use' calls by other modules. >> > I just reread your original post... I think I may know what the problem is (maybe). Are you using handlers? SetHandler perl-script PerlModule My::Special::Module PerlHandler My::Special::Module If that is the case, My::Special::Module won't be loaded and compiled until the very first time that someone hits /whatever. This explains the missing modules in %INC (I think), but it does not explain the problem with Apache::StatINC. > >Out of curiosity, I took our configuration file and changed all >the 'PerlModule' directives to 'use' calls (inside a block), >and lo and behold, they all appeared in %INC. >> > And did this fix your problem with Apache::StatINC too? Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: PerlModule not updating %INC
Hello, I hate to keep banging this old drum, but since I was able to reproduce this problem (but not solve it), I figured I'd recycle it again. Perrin said earlier that this was fixed in 1.26, but I am indeed using 1.26 and the problem persists. Stas suggested upgrading perl to 5.6.1 -- I did so, recompiled mod_perl, and the problem persists. I didn't try upgrading the perl on my darwin box, but the fact that I get the same result there is telling. Can anyone tell me what the fix was from 1.25 to 1.26? Maybe there's a clue there. Thanks, David > >I'm still having this problem, and I've discovered that it is also happening on my >darwin box. This is enough to lead me to believe the problem is bona fide. > >To recap: problem occurs on : > Darwin (MacOS X) Perl 5.6.0 / Apache 1.3.20 / mod_perl 1.26 > Red-Hat Linux (7.1) Perl 5.6.0 / Apache 1.3.20 / mod_perl 1.26 > Red-Hat Linux (7.1) Perl 5.6.1 / Apache 1.3.20 / mod_perl 1.26 > >Problem : PerlModule does not cause %INC to be updated, but 'use' does > >Symptoms : Apache::StatINC does not work for said modules. Said modules do not >appear in Apache::Status "loaded modules" page, but do appear in the Inheritance tree. > >Ideas? > >Thanks, >David > >>Date: Thu, 18 Oct 2001 12:57:27 -0800 >>To: Stas Bekman <[EMAIL PROTECTED]> >>From: David Pisoni <[EMAIL PROTECTED]> >>Subject: Re: PerlModule not updating %INC >>Cc: Perrin Harkins <[EMAIL PROTECTED]>, [EMAIL PROTECTED] >>Bcc: >>X-Attachments: >> >>At 1.13 +0800 10/17/2001, Stas Bekman wrote: >>>David Pisoni wrote: >>> >At 18.23 -0400 10/11/2001, Perrin Harkins wrote: > >>>At 18.07 -0400 10/11/2001, Perrin Harkins wrote: >>> >We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26. > Are you sure? There was a problem with %INC and PerlModule, but I >>thought >> it was fixed in 1.26. - Perrin >>>Indeed, like I said, I tested it by dumping %INC myself -- the modules are >>> >>indeed missing when loaded with PerlModule. >> >>No, I meant are you sure you're running 1.26? Please doublecheck it, since >>this sounds so much like the bug from the previous release. >>- Perrin >> >Indeed, here's the signature from Apache::Status : > > Embedded Perl version v5.6.0 for Apache/1.3.20 (Unix) (Red-Hat/Linux) >mod_perl/1.26 > >Apache.pm shows v1.27 (that's a little weird, but I assume unimportant.) > >Thanks, >David > So... any ideas on this one? >>> >>> >>>have you tried 5.6.1? 5.6.0 is very buggy. >>> >> >>Just tried it. Fresh build of 5.6.1, and mod_perl 1.26 against it. The problem >persists -- %INC is incomplete vs. my actual loaded modules, missing what was loaded >with PerlModule directives. >> >>What should I try next. :-) >> >>David Original Message : >Hello, > >We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26. We are running these >on a RedHat Linux 7.1, kernel v2.4.2 system. > >We have been doing development using mod_perl, but finding that Apache::StatINC was >not working as expected (i.e., we needed to restart the web server in order to see >our module changes in effect.) Our apache config files preload all necessary modules >at start time using the 'PerlModule' directive. When I started peeking through >Apache::Status I found that although all of our loaded modules appear in the >"Inheritance Tree" and the "ISA Tree", most of them did not appear in the "Loaded >Modules" section. (I also did a test handler with a dump of the contents of %INC, >and said modules were missing.) The only modules of ours which DID appear were those >which were ALSO called for with 'use' calls by other modules. > >Out of curiosity, I took our configuration file and changed all the 'PerlModule' >directives to 'use' calls (inside a block), and lo and behold, they all >appeared in %INC. > >I could not find any documentation suggesting that the PerlModule directive would >successfully load a module while circumventing %INC, nor do I recall in my previous >projects developed using mod_perl having this problem. (Although I've been away >awhile -- maybe I forget.) > >Any guidance? > >Thanks,
RE: [OT] Re: How to create a browser popup window
> You must include code to deal with the fact that you may have already
> opened a popup window. Something like this:
That is simply not true. window.open() with a named window ('popupwin', in
your example) ALWAYS reuses that window, on every browser I've ever been
able to test. The second call to window.open, with a new URL, simply
refreshes the contents of the popup w/ the new URL. Note, this is *only*
true for named windows. Windows without a window name string as the second
parameter to window.open() will open a new window every time.
It can, however, be a good idea to explicitly call focus() on your child
window, because in the situation I've just mentioned, if the child window's
url is refreshed, it is NOT automatically brought to the foreground.
The original post was wondering how to put mod_perl output in a popup
window. The answer is simply top call window.open() with the URL of the
mod_perl handler as its location.
If one is trying to be "responsible" about the window(s) being open, adding
a link like
CLICK HERE CLOSE THIS WINDOW
in the child window is usually reasonably simple for the user to understand.
Of course, the normal caveats about users understanding something still
apply...
A corrected version of your sample script follows. It's much simpler now...
:-)
>
>