Re: "Streaming" compression of output from mod_perl handler?

[Nicholas Oxhøj]

> I'm not sure that lynx can handle compressed response on the fly -
> it uses gzip in pipe.
> The best way to test it using netcat.

Well, lynx didn't decompress it, it just output the gzip compressed content to stdout. 
As I didn't have netcat readily available on the machine, I instead put an strace on 
lynx, to be absolutely sure, that it didn't receive any output until the very end - 
and it didn't :-(

> I you like to test I can make patch for mod_deflate to flush Apache.
> But if major browsers can not handle compressed content on the fly
> it's not valuable.

That would be an interesting patch, but with approx 450KB of uncompressed HTML, I 
would expect mod_deflate to receive compressible input, regardless if the content 
producer specifically flushes or not. But I might have misunderstood something.

Regarding the browsers ability to handle compressed content on the fly, we probably 
won't know until I find a module that is able to produce such output.

Nicholas Oxhøj

Re: "Streaming" compression of output from mod_perl handler?

[Nicholas Oxhøj]

> I've developed an Apache::Dynagzip handler for Outlook 
> Technologies, Inc. to
> serve the dynamic content with the option to control the size of the
> chunk(s). It works fine (as standing along, and within the 
> Apache::Filter
> Chain). Using the Apache::Dynagzip you have several options 
> to control your
> chunk size(s). You can even control the size of every chunk 
> from the source
> generator: Just send the mask of the end of the chunk to the
> Apache::Dynagzip within the outgoing content/stream. (You 
> might wish to send
> your header to the client browser while creating the rest of 
> the body...)
> Otherwise, it is buffering the outgoing stream up to the length of the
> chunk's minimum size , which is not less then declared (2K default).

It certainly sounds very promising.
Can I find the Apache::Dynagzip handler anywhere - Google returns nothing...

> Is your handler Apache::Filter Chain compatible?

Not at the moment. But as it is only a content producer, isn't the only requirement, 
that I insert "$r->filter_register()" somewhere near the top of the handler, before 
returning any output?
At least that is what I did, when I tried to test the Apache::Compress handler (which 
I didn't succeed in getting to work properly).

Nicholas Oxhøj

Re: RE: [Samba authorization]

[Carlos Ramirez]

Here are some fixes I incorporated into my private copy of
Authen::Smb and Apache::AuthenSmb modules. These changes 
are based on some discussion I found in the modperl 
mailing list posted on Thu, 16 Sep 1999 by Matt Arnold. I
basically copied Matt's suggestions and added them in.
I was getting the same error messages but after I
incorporated theses changes, it to fixed the problem on
SUN Sparc Solaris 2.5.1..2.8.
 
=Begin Snippet from mailing list
 
The resulting additions to Authen::Smb look like this:
 
  use Fcntl qw(:flock);
  ...
  open S, "> /full/path/to/AuthenSmb.lck" or die "Can't open
  AuthenSmb.lck: $!\n";
  flock S, LOCK_EX;
  my $res = Valid_User($username, $password, $server, $backup, $domain);
 
  close S;

In short, I ended up adding
the following two lines to Apache::AuthenSmb.
 
  use Memoize;
  memoize('Authen::Smb::authen');
 
=End of Snippet
 
I contacted the author of Apache::AuthenSmb (a long time
ago) and asked him if he could add these changes into 
the module. He stated he no longer has access to machines
where he can test his module and asked me to post
it in the modperl mailing list (which I never did).
I used this module extensively in our environment and 
have also added some other nice features.  Anyhow, if 
the author can no longer maintain it, i'd be glad ty 
update it ;)

Since, this fix also requires that Authen::Smb to be
modified, maybe the author of the cool Authen::Smb module
add some option to allow a lock file or force it to use a
lock file (??). 

Something along the lines:
sub authen {
my @args = @_;
 
# Truncate everything to length 80 to avoid poor coding practices in the
# smbvalid.a (buffer overflows) PMK--fixme in smbvalid.a when possible.
for my $i ( 0..$#args ) {
  $args[$i] = substr($args[$i], 0, 80);
}

my($username, $password, $server, $backup, $domain, $lockfile) = @args;
my $res;
if ($lockfile) {
   open  L, "> $lockfile" or die "Can't open AuthenSmb.lck: $!\n";
   flock L, LOCK_EX;
   $res = Valid_User($username, $password, $server, $backup, $domain);
   close L;
}
else {
   $res = Valid_User($username, $password, $server, $backup, $domain);
}
 
return $res;
}
 
 
Anyhow, hope this helps. 


-Carlos

> 
> From: "Stathy G. Touloumis" <[EMAIL PROTECTED]>
> Date: 2002/02/19 Tue PM 02:00:35 CST
> To: "Andrew Afliatunov" <[EMAIL PROTECTED]>, 
>   "Mod_perl" <[EMAIL PROTECTED]>
> Subject: RE: [Samba authorization]
> 
> You should probably contact the maintainers of Apache::AuthSmb and
> kindly ask them to look into the problem : )  If I had some Sparcs lying
> around
> I would be willing to look into it but I don't ; )
> 
> > Please, let's continue discussing my problem. Remind you, that I
> > installed mod_perl, Authen-Smb-0.91 and Apache-AuthenSmb-0.60 for
> > authorization in apache against NT server. And I get this error in
> > apache error.log file:
> > "Undefined subroutine &Apache::AuthenSmb::handler called".
> > In discussion we stopped at the point that I have wrong Smb.so file,
> > because when I put "PerlModule Apache::AuthenSmb" in my httpd.conf file
> > I get
> > --
> > Syntax error on line 346 of /usr/local/apache/conf/httpd.conf:
> > Can't load
> > '/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/Authen/Smb/Smb.so'
> > for
> > module Authen::Smb: ld.so.1: /usr/local/apache/bin/httpd: fatal:
> > relocation error: file
> > /usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/Authen/Smb/Smb.so:
> > symbol main: referenced symbol not found at
> > /usr/local/lib/perl5/5.6.1/sun4-solaris/DynaLoader.pm line 206.
> >  at /usr/local/lib/perl5/site_perl/5.6.1/Apache/AuthenSmb.pm line 5
> > Compilation failed in require at
> > /usr/local/lib/perl5/site_perl/5.6.1/Apache/AuthenSmb.pm line 5.
> > BEGIN failed--compilation aborted at
> > /usr/local/lib/perl5/site_perl/5.6.1/Apache/AuthenSmb.pm line 5.
> > Compilation failed in require at (eval 3) line 3.
> > --
> > when making 'apachectl configtest'. I tried to reinstall AuthenSmb with
> > its default options (default Makefile.PL), - no success.
> > Maybe I must install it with some different from default options? Who
> > knows what are such options? What is configurable there? Or what may be
> > done with my Smb.so in oder Authen:Smb to understand it?
> >
> 
> 

Re: [Samba authorization]

[Carlos Ramirez]

Here's the link to the post on modperl mailing list:
http:[EMAIL PROTECTED]

-Carlos


Carlos Ramirez wrote:
> 
> Here are some fixes I incorporated into my private copy of
> Authen::Smb and Apache::AuthenSmb modules. These changes
> are based on some discussion I found in the modperl
> mailing list posted on Thu, 16 Sep 1999 by Matt Arnold. I
> basically copied Matt's suggestions and added them in.
> I was getting the same error messages but after I
> incorporated theses changes, it to fixed the problem on
> SUN Sparc Solaris 2.5.1..2.8.
> 
> =Begin Snippet from mailing list
> 
> The resulting additions to Authen::Smb look like this:
> 
>   use Fcntl qw(:flock);
>   ...
>   open S, "> /full/path/to/AuthenSmb.lck" or die "Can't open
>   AuthenSmb.lck: $!\n";
>   flock S, LOCK_EX;
>   my $res = Valid_User($username, $password, $server, $backup, $domain);
> 
>   close S;
> 
> In short, I ended up adding
> the following two lines to Apache::AuthenSmb.
> 
>   use Memoize;
>   memoize('Authen::Smb::authen');
> 
> =End of Snippet
> 
> I contacted the author of Apache::AuthenSmb (a long time
> ago) and asked him if he could add these changes into
> the module. He stated he no longer has access to machines
> where he can test his module and asked me to post
> it in the modperl mailing list (which I never did).
> I used this module extensively in our environment and
> have also added some other nice features.  Anyhow, if
> the author can no longer maintain it, i'd be glad ty
> update it ;)
> 
> Since, this fix also requires that Authen::Smb to be
> modified, maybe the author of the cool Authen::Smb module
> add some option to allow a lock file or force it to use a
> lock file (??).
> 
> Something along the lines:
> sub authen {
> my @args = @_;
> 
> # Truncate everything to length 80 to avoid poor coding practices in the
> # smbvalid.a (buffer overflows) PMK--fixme in smbvalid.a when possible.
> for my $i ( 0..$#args ) {
>   $args[$i] = substr($args[$i], 0, 80);
> }
> 
> my($username, $password, $server, $backup, $domain, $lockfile) = @args;
> my $res;
> if ($lockfile) {
>open  L, "> $lockfile" or die "Can't open AuthenSmb.lck: $!\n";
>flock L, LOCK_EX;
>$res = Valid_User($username, $password, $server, $backup, $domain);
>close L;
> }
> else {
>$res = Valid_User($username, $password, $server, $backup, $domain);
> }
> 
> return $res;
> }
> 
> 
> Anyhow, hope this helps.
> 
> -Carlos
> 
> >
> > From: "Stathy G. Touloumis" <[EMAIL PROTECTED]>
> > Date: 2002/02/19 Tue PM 02:00:35 CST
> > To: "Andrew Afliatunov" <[EMAIL PROTECTED]>,
> >   "Mod_perl" <[EMAIL PROTECTED]>
> > Subject: RE: [Samba authorization]
> >
> > You should probably contact the maintainers of Apache::AuthSmb and
> > kindly ask them to look into the problem : )  If I had some Sparcs lying
> > around
> > I would be willing to look into it but I don't ; )
> >
> > > Please, let's continue discussing my problem. Remind you, that I
> > > installed mod_perl, Authen-Smb-0.91 and Apache-AuthenSmb-0.60 for
> > > authorization in apache against NT server. And I get this error in
> > > apache error.log file:
> > > "Undefined subroutine &Apache::AuthenSmb::handler called".
> > > In discussion we stopped at the point that I have wrong Smb.so file,
> > > because when I put "PerlModule Apache::AuthenSmb" in my httpd.conf file
> > > I get
> > > --
> > > Syntax error on line 346 of /usr/local/apache/conf/httpd.conf:
> > > Can't load
> > > '/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/Authen/Smb/Smb.so'
> > > for
> > > module Authen::Smb: ld.so.1: /usr/local/apache/bin/httpd: fatal:
> > > relocation error: file
> > > /usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/Authen/Smb/Smb.so:
> > > symbol main: referenced symbol not found at
> > > /usr/local/lib/perl5/5.6.1/sun4-solaris/DynaLoader.pm line 206.
> > >  at /usr/local/lib/perl5/site_perl/5.6.1/Apache/AuthenSmb.pm line 5
> > > Compilation failed in require at
> > > /usr/local/lib/perl5/site_perl/5.6.1/Apache/AuthenSmb.pm line 5.
> > > BEGIN failed--compilation aborted at
> > > /usr/local/lib/perl5/site_perl/5.6.1/Apache/AuthenSmb.pm line 5.
> > > Compilation failed in require at (eval 3) line 3.
> > > --
> > > when making 'apachectl configtest'. I tried to reinstall AuthenSmb with
> > > its default options (default Makefile.PL), - no success.
> > > Maybe I must install it with some different from default options? Who
> > > knows what are such options? What is configurable there? Or what may be
> > > done with my Smb.so in oder Authen:Smb to understand it?
> > >
> >
> >

-- 
-
Carlos Ramirez + Boeing + Human Flight & Space Exploration +
714.372.4181
-

Re: Installing Perl::Magick

[Ron Savage]

Aaron

See below.

Cheers
Ron Savage
[EMAIL PROTECTED]
http://savage.net.au/index.html

> There is a package available in ppm for ActiveState Perl.
> There is a short write up on it PerlMonks
> http://www.perlmonks.org/index.pl?node_id=140321

Thanx.

I was not actually asking for same. There is a package for V 5.4.3.2 here:
http://www.dylanbeattie.net/magick/downloads.html

I'm supplying this URI just for completeness.

Re: Installing Perl::Magick

[Aaron Johnson]

There is a package available in ppm for ActiveState Perl.
There is a short write up on it PerlMonks
http://www.perlmonks.org/index.pl?node_id=140321

Aaron Johnson

Ron Savage wrote:
> 
> lamp
> 
> See below.
> 
> Cheers
> Ron Savage
> [EMAIL PROTECTED]
> http://savage.net.au/index.html
> 
> > Magick.xs:76:24: magick/api.h: No such file or directory
> 
> This means you must, repeat must, have the ImageMagick source code on tap to compile 
>PerlMagick. Being lazy, I wait for someone to
> create an ActiveState ppm file...
> 
> As someone else mentioned, there are ImageMagick mailing lists:
> http://www.imagemagick.org/www/magick-list.html

Re: [OT-ish] Session refresh philosophy

[Perrin Harkins]

> I built and use a module that encodes a session hash into a number of
hidden
> fields with a security MD5 sum.

Sounds a lot like CGI::SecureState.  Have you ever looked at it?

- Perrin

RE: [OT-ish] Session refresh philosophy

[David Harris]

David Harris [[EMAIL PROTECTED]] wrote:
[snip]
> I've attached some code. To use the code, you'll have to replace the
> module FreezeThawLite with Storable. Also, beware the \r\n newlines.
> (I pulled this out of CVS on my windows desktop.)

I forgot to actually attach the code

David




package Fusion::FormContainer;
use strict;

use Digest::MD5 ();
use MIME::Base64 ();
use FreezeThawLight ();
use Compress::Zlib ();

use Carp;

# this respresents a securty hole if we open-source this module.. the securtiy string
# needs to be passed as confguration at that point somehow.

sub _create_security_string
{
my $string = shift;

my $secret = add($string);
$ctx->add($secret);
return $ctx->hexdigest;
}

sub encode
{
my $info = shift;
my $prefix = shift;

my $string = 
MIME::Base64::encode(Compress::Zlib::compress(FreezeThawLight::freeze($info)));
$string =~ s/\n$//;

my @array;

push @array, ("${prefix}_fc_security", _create_security_string($string));

my $part_number = 0;
foreach my $part ( split "\n", $string ) {
my $part_number_string = sprintf("%.3d", $part_number);
push @array, ("${prefix}_fc_part$part_number_string", $part);
$part_number++;
}

if ( wantarray ) {
return @array;
} else {
my $html;
while ( @array ) {
my $name = shift(@array);
my $value = shift(@array);
$html .= <
EOT
}
return $html;
}
}

sub decode
{
my $apr = shift;
my $prefix = shift;

my $security = $apr->param("${prefix}_fc_security");

my @string_parts;
my $part_number = 0;
while ( 1 ) {
my $part_number_string = sprintf("%.3d", $part_number);
my $part = $apr->param("${prefix}_fc_part$part_number_string");
last if ( $part eq "" );
push @string_parts, $part;
$part_number++;
}
my $string = join "\n", @string_parts;

croak "tampered or malformed FormContainer: securty string and string don't 
match"
if ( _create_security_string($string) ne $security );

return 
FreezeThawLight::thaw(Compress::Zlib::uncompress(MIME::Base64::decode($string)));
}

1;

RE: [OT-ish] Session refresh philosophy

[David Harris]

Drew Taylor [mailto:[EMAIL PROTECTED]]:
> And that is what I am doing for a small project I'm working on now. In my
> case, I'm not sure about the capabilities of the remote server, and I know
> for sure that I don't have a database available, so session information is
> saved via hidden form fields. It's primitive, but was actually a bit of a
> challenge to make sure a (unused) hidden field and a visible form element
> don't appear in the same . Not my first choice, but it definitely
works.

I built and use a module that encodes a session hash into a number of hidden
fields with a security MD5 sum. The encoded information is serialized,
gzipped, Base64 encoded, and then split into reasonable length hidden
fields. It looks like this:





This way, you don't have to worry about creating hidden form fields in your
templates for every variable you need to encode. In your perl, simply call
the session encode and decode methods. You are also assured that nobody
messed with the data.

You can easily "pass" arbitrarily complex session information from one page
to another without using a database, and the session info is truly tied to
the *page*. Use of the back button, therefore, doesn't break anything.

I've attached some code. To use the code, you'll have to replace the module
FreezeThawLite with Storable. Also, beware the \r\n newlines. (I pulled this
out of CVS on my windows desktop.)

HTH.

David

Re: file globbing question

[Cees Hek]

On Wed, 2002-02-20 at 13:27, John Stauffacher wrote:
> All,
> 
> I am a bit confused as to what httpd.conf directives need to be used in
> order to get apache to execute a PerlHandler when it encounters a
> certain file type. What I want to do:
>   Execute a handler whenever a *.qw file is accessed. The same
> handler whether or not the file exists and not look for the file. So the
> user makes the request: get /somewhere/my.qw and gets the response
> "moo". Then they request /other/place/boo.qw and gets the response
> "moo". I have tried using a  directive, but it envokes the
> handler, then looks for the file and throws a 404. Any ideas?

The  directive is the right way to go.  Are you sure you are
returning OK in your Handler?  If you return something else (like
DECLINED) then Apache will take over the request and handle it in the
default manner (ie look up the file).  Returning OK lets Apache know
that the request was dealt with appropriately and it can move on to the
next phase.

Cees

file globbing question

[John Stauffacher]

All,

I am a bit confused as to what httpd.conf directives need to be used in
order to get apache to execute a PerlHandler when it encounters a
certain file type. What I want to do:
Execute a handler whenever a *.qw file is accessed. The same
handler whether or not the file exists and not look for the file. So the
user makes the request: get /somewhere/my.qw and gets the response
"moo". Then they request /other/place/boo.qw and gets the response
"moo". I have tried using a  directive, but it envokes the
handler, then looks for the file and throws a 404. Any ideas?

-John Stauffacher

++
John Stauffacher
Network Administrator
Chapman University
[EMAIL PROTECTED]
714-628-7249

Re: [OT-ish] Session refresh philosophy

[Milo Hyson]

On Tuesday 19 February 2002 02:55 pm, Perrin Harkins wrote:
> Incidentally, this is mostly the same thing as what Jeffrey Baker mentioned
> a few days ago about storing state entirely inside a cookie with a message
> digest.  The only difference is that by sticking it in a form element
> you're attaching it to a specific page.

That's not a bad idea. I guess if you're paranoid about snooping you could 
always encrypt the cookie.

-- 
Milo Hyson
CyberLife Labs, LLC

Re: [OT-ish] Session refresh philosophy

[Drew Taylor]

At 05:55 PM 2/19/2002 -0500, Perrin Harkins wrote:
>Incidentally, this is mostly the same thing as what Jeffrey Baker mentioned
>a few days ago about storing state entirely inside a cookie with a message
>digest.  The only difference is that by sticking it in a form element you're
>attaching it to a specific page.

True. I was very intrigued by his approach, and might use something like 
that to increase the security of my app by verifying the hidden form field 
contents. I suppose I could follow his approach, but the amount of data I 
need to store could possibly overwhelm the 4KB cookie limit. In this case, 
simple was better - simple application, simple session. And I know I can 
count on every browser implementing forms. :-)

Drew


Drew Taylor JA[P|m_p|SQL]H
http://www.drewtaylor.com/  Just Another Perl|mod_perl|SQL Hacker
mailto:[EMAIL PROTECTED]  *** God bless America! ***

Re: [OT-ish] Session refresh philosophy

[Perrin Harkins]

> And that is what I am doing for a small project I'm working on now. In my
> case, I'm not sure about the capabilities of the remote server, and I know
> for sure that I don't have a database available, so session information is
> saved via hidden form fields. It's primitive, but was actually a bit of a
> challenge to make sure a (unused) hidden field and a visible form element
> don't appear in the same . Not my first choice, but it definitely
works.

Incidentally, this is mostly the same thing as what Jeffrey Baker mentioned
a few days ago about storing state entirely inside a cookie with a message
digest.  The only difference is that by sticking it in a form element you're
attaching it to a specific page.

- Perrin

Re: [OT-ish] Session refresh philosophy

[Drew Taylor]

And that is what I am doing for a small project I'm working on now. In my 
case, I'm not sure about the capabilities of the remote server, and I know 
for sure that I don't have a database available, so session information is 
saved via hidden form fields. It's primitive, but was actually a bit of a 
challenge to make sure a (unused) hidden field and a visible form element 
don't appear in the same . Not my first choice, but it definitely works.

Drew

At 11:42 AM 2/19/2002 +, Ged Haywood wrote:
>Hi there,
>
>On Mon, 18 Feb 2002, Milo Hyson wrote:
>
> > maybe I'm just approaching the problem incorrectly. If one is doing a
> > shopping-cart-style application (whereby someone selects/configures 
> multiple
> > items before they're ultimately committed to a database) how else would 
> you
> > do it? There has to be some semi-persistent (i.e. inter-request) data 
> where
> > selections are stored before they're confirmed.
>
>You can for example send a hidden  object back and forth between
>your Client and the app.

Drew Taylor JA[P|m_p|SQL]H
http://www.drewtaylor.com/  Just Another Perl|mod_perl|SQL Hacker
mailto:[EMAIL PROTECTED]  *** God bless America! ***

Re: Installing Perl::Magick

[Ron Savage]

lamp

See below.

Cheers
Ron Savage
[EMAIL PROTECTED]
http://savage.net.au/index.html

> Magick.xs:76:24: magick/api.h: No such file or directory

This means you must, repeat must, have the ImageMagick source code on tap to compile 
PerlMagick. Being lazy, I wait for someone to
create an ActiveState ppm file...

As someone else mentioned, there are ImageMagick mailing lists:
http://www.imagemagick.org/www/magick-list.html

Re: "Streaming" compression of output from mod_perl handler?

[Slava Bizyayev]

I've developed an Apache::Dynagzip handler for Outlook Technologies, Inc. to
serve the dynamic content with the option to control the size of the
chunk(s). It works fine (as standing along, and within the Apache::Filter
Chain). Using the Apache::Dynagzip you have several options to control your
chunk size(s). You can even control the size of every chunk from the source
generator: Just send the mask of the end of the chunk to the
Apache::Dynagzip within the outgoing content/stream. (You might wish to send
your header to the client browser while creating the rest of the body...)
Otherwise, it is buffering the outgoing stream up to the length of the
chunk's minimum size , which is not less then declared (2K default).

Is your handler Apache::Filter Chain compatible?

Thanks,
Slava Bizyayev

- Original Message -
From: "Igor Sysoev" <[EMAIL PROTECTED]>
To: "Nicholas Oxhoj" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, February 19, 2002 4:12 AM
Subject: Re: "Streaming" compression of output from mod_perl handler?


> On Tue, 19 Feb 2002, [iso-8859-1] Nicholas Oxhøj wrote:
>
> > I am looking for an Apache module which will allow me to compress the
output of my mod_perl handler (a "native" handler, i.e. not running under
Apache::Registry). But since my handler can potentially take a long time to
finish, the output has to be compressed in a "streaming" fashion (or in
small blocks) so that the browser will start receiving data before my
handler has completely finished.
> >
> > I have been experimenting with all the different Apache compression
modules I have been able to find, but have not been able to get the desired
result. I have tried Apache::GzipChain, Apache::Compress, mod_gzip and
mod_deflate, with different results. One I cannot get to work at all. Most
work, but seem to collect all the output before compressing it and sending
it to the browser.
> >
> > There also seems to be an issue about the new HTTP/1.1 "chunked"
transfer-encoding. For instance, mod_gzip will not compress chunked output,
unless you allow it to "dechunk" it by collecting all the output and
compressing it as one big block.
> >
> > So I am basically looking for anyone who has had any success in
achieving this kind of "streaming" compression, who could direct me at an
appropriate Apache module.
>
> What mod_deflate did you try ? My or Apache 2.0 ?
> I can comment my mod_deflate.
> First, mod_deflate did not collect all output before compressing - it
> compress it on the fly. But it emits compressed content in 8K block.
> It's Apache's HUGE_STRING_LEN #define and it can be changed in sources.
> Besides if some module flushes output then mod_deflate would flushed it
too.
>
> mod_deflate did not have problems with chunked transfer-encoding
> because it compress content before Apache start to make chunks.
> mod_deflate remove Content-Length header so compressed content
> would be sent to client chunked (HTTP/1.1) or not (HTTP/1.0).
>
> Igor Sysoev
>
>

Re: [OT] Really need Comments! very strange bug that happens onlyon Linux.

[Ged Haywood]

Hi all,

On 19 Feb 2002, Randal L. Schwartz wrote:

> Yes.  Learn that 1/10 doesn't have a precise representation in binary,
> so *all* floating point numbers are "approximate".

Well, maybe not 0.5, 0.25,... :)

73,
Ged.

RE: [Samba authorization]

[Stathy G. Touloumis]

You should probably contact the maintainers of Apache::AuthSmb and
kindly ask them to look into the problem : )  If I had some Sparcs lying
around
I would be willing to look into it but I don't ; )

> Please, let's continue discussing my problem. Remind you, that I
> installed mod_perl, Authen-Smb-0.91 and Apache-AuthenSmb-0.60 for
> authorization in apache against NT server. And I get this error in
> apache error.log file:
> "Undefined subroutine &Apache::AuthenSmb::handler called".
> In discussion we stopped at the point that I have wrong Smb.so file,
> because when I put "PerlModule Apache::AuthenSmb" in my httpd.conf file
> I get
> --
> Syntax error on line 346 of /usr/local/apache/conf/httpd.conf:
> Can't load
> '/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/Authen/Smb/Smb.so'
> for
> module Authen::Smb: ld.so.1: /usr/local/apache/bin/httpd: fatal:
> relocation error: file
> /usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/Authen/Smb/Smb.so:
> symbol main: referenced symbol not found at
> /usr/local/lib/perl5/5.6.1/sun4-solaris/DynaLoader.pm line 206.
>  at /usr/local/lib/perl5/site_perl/5.6.1/Apache/AuthenSmb.pm line 5
> Compilation failed in require at
> /usr/local/lib/perl5/site_perl/5.6.1/Apache/AuthenSmb.pm line 5.
> BEGIN failed--compilation aborted at
> /usr/local/lib/perl5/site_perl/5.6.1/Apache/AuthenSmb.pm line 5.
> Compilation failed in require at (eval 3) line 3.
> --
> when making 'apachectl configtest'. I tried to reinstall AuthenSmb with
> its default options (default Makefile.PL), - no success.
> Maybe I must install it with some different from default options? Who
> knows what are such options? What is configurable there? Or what may be
> done with my Smb.so in oder Authen:Smb to understand it?
>

Re: [OT] Apache Config Problem

[Robert Landrum]

At 2:22 PM -0500 2/19/02, Stephen Reppucci wrote:
>So, if you virtual host was something like:
>
>Listen 192.168.0.100:8080
>
>  ServerName  www.foo.com
>  ServerAlias foo.com
>  Port 80
>  ...
>
>
>Then (assuming your bigip sends requests for foo.com to
>192.168.0.100:8080) generated urls will be to
>'http://www.foo.com:80/' (I think the ':80' is dropped as the
>default port...)
>
>

A very important addition to this is to make sure UseCononicalName is
turned on. ;-)

30 minutes of reading about mod_rewrite, 4 minutes to recompile 
apache, 2 minutes of coding it, 20 minutes of testing, and a 10 
second fix was all it took.  Doh!

Thanks everyone,

Rob

--
When I used a Mac, they laughed because I had no command prompt. When 
I used Linux, they laughed because I had no GUI.  

Re: [OT] Apache Config Problem

[Stephen Reppucci]

Yes, just add a 'Port 80' line to your VirtualHost section.

While many folks assume that this directive is for telling apache
which port to listen on (it's not -- the Listen directive does
that...), it's actually a setting that instructs Apache to use the
named port in any generated urls.  (At least, that's my
understanding of it, and it appears to work like that for me...)

UseCanonical tells apache to always use the canonical ("ServerName")
setting in generated urls -- that allows you to have a ServerAlias
for something like 'foo.com', and have generated urls redirect to to
'www.foo.com'.

So, if you virtual host was something like:

Listen 192.168.0.100:8080

  ServerName  www.foo.com
  ServerAlias foo.com
  Port 80
  ...


Then (assuming your bigip sends requests for foo.com to
192.168.0.100:8080) generated urls will be to
'http://www.foo.com:80/' (I think the ':80' is dropped as the
default port...)

HTH,


On Tue, 19 Feb 2002, Robert Landrum wrote:

> I'm trying to do something really simple and trying to avoid writing
> an Modperl handler to do it.
>
> We have a website behind a bigip running on port 8080.  When someone
> requests a URL that doesn't end with a slash, it's redirected to
> http://host:8080/path/ .  I tried turning off UseCononicalName, but
> it didn't have any effect.
>
> Any suggestions?
>
> Thanks,
>
> Rob
>
> --
> When I used a Mac, they laughed because I had no command prompt. When
> I used Linux, they laughed because I had no GUI.
>

-- 
Steve Reppucci   [EMAIL PROTECTED] |
Logical Choice Software  http://logsoft.com/ |
=-=-=-=-=-=-=-=-=-=-  My God!  What have I done?  -=-=-=-=-=-=-=-=-=-=

Re: [OT] Really need Comments! very strange bug that happens only on Linux.

[___cliff rayman___]

yes - this is VERY off topic for a mod_perl mailing list.

remember, computers are binary machines.  your 323.82
was not stored like you might think.  the computer approximated
using binary math.  when you scaled it four places to the left,
you saw the results of the approximation.  FreeBSD appears
more accurate on this particular calculation, but it might
be less so with different input.

check out one of the Math:: packages on CPAN,
you should be able to find something that will give you the
accuracy required for your application.


Vlad Safronov wrote:

> While testing my perl scripts I found a strange bug that happens only on
> Linux (RH 6.2, 7.0),
> See the code below. Before your read the all text, tell me what's the Buffer
> value?
> "3238200"? The answer is NO! Try this example on your Linux box
>
> SOURCE test.c:
> -=-=-=-=
> #include 
> #include 
>
> main () {
> double Sum, ResultSum;
> ResultSum = 1;
> Sum = 323.82;
> char *Buffer = new char[255];
> sprintf(Buffer, "%d", (long)(Sum * ResultSum));
> printf("Buffer = [%s], Sum = %.4f, Sum * Result = %.4f\n", Buffer, Sum, (Sum
> * ResultSum));
>
> return 0;
> }
>
> RESULTS
> -=-=-=-=
> now compile on Linux RedHat 6.2 with gcc version egcs-2.91.66 19990314/Linux
> (egcs-1.1.2 release)
> Output:
> $ g++ test.c
> $ ./a.out
> Buffer = [3238199], Sum = 323.8200, Sum * Result = 3238200.
> -=-=-=-=
>
> the Buffer value is very strange! I have no ideas how Buffer can be 3238199!
> FreeBSD (old 3.x) works well and Buffer=3238200 as it should be, but on
> Linux 6.2, 7.0 it is 3238199..

--
___cliff [EMAIL PROTECTED]http://www.genwax.com/

Re: [OT] Apache Config Problem

[Geoffrey Young]

Robert Landrum wrote:
> 
> I'm trying to do something really simple and trying to avoid writing
> an Modperl handler to do it.
> 
> We have a website behind a bigip running on port 8080.  When someone
> requests a URL that doesn't end with a slash, it's redirected to
> http://host:8080/path/ .  I tried turning off UseCononicalName, but
> it didn't have any effect.
> 
> Any suggestions?

I have a setup like this:

  
ServerName foo.example.com
Port 80
  ...
  
ServerName foo.example.com
Port 443

behind bigIP... so, traffic to foo.example.com on 443 at the bigIP
level is sent to my.transparent.server at 20001.  mod_dir and others
use the Port directive to "fix" redirects, which isn't exactly
self-evident...

--Geoff

Re: [OT] Apache Config Problem

[Brian Reichert]

On Tue, Feb 19, 2002 at 01:41:44PM -0500, Robert Landrum wrote:
> I'm trying to do something really simple and trying to avoid writing 
> an Modperl handler to do it.
> 
> We have a website behind a bigip running on port 8080.  When someone 
> requests a URL that doesn't end with a slash, it's redirected to 
> http://host:8080/path/ .  I tried turning off UseCononicalName, but 
> it didn't have any effect.

Er, why not use mod_rewrite?  Maybe overkill, but this is what it's for...

> Any suggestions?

  
 
> Thanks,
> 
> Rob

-- 
Brian 'you Bastard' Reichert<[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA Intel architecture: the left-hand path

OT Re: Installing Perl::Magick

[Marcel Weber]

Sorry, I did not meant giving silly comments ;-) I just saw your email 
[EMAIL PROTECTED] so I thought you would usually work as root.

Marcel



Am Dienstag den, 19. Februar 2002, um 17:22, schrieb Jonathan M. Hollin:

> :: I don't know anything about your problem. I just wanted to
> :: give you a
> :: hint, as you said, that you were a complete linux newbie:
> ::
> :: Do not work as root. It is dangerous! The root account should be for
> :: installation, configuration of the system and where it cannot be
> :: avoided. I always have some regular user account for working on my
> :: servers and as soon that I want to change something I do a "su". The
> :: best is even to disable root logins on the console and
> :: especially via
> :: ssh / telnet. It gives you some extra security as everyone
> :: knows, that
> :: there must be a root account on a unix box.
>
> Marcel, I was working as root after an "su" as I couldn't install
> Image::Magick under my own account.
>
> As far as security goes - I /think/ I have configured my box with only
> the www and ssh services available, everything else is locked down (he
> says, hopefully).
>
> :: Best regards and enjoy linux!
>
> Thank you.  So far I'm enjoying Linux tremendously.  It's really
> challenging, but fun and intellectually stimulating.  I only wish I'd
> started years ago.
>
>
> Jonathan M. Hollin - WYPUG Co-ordinator
> West Yorkshire Perl User Group
> http://wypug.pm.org/
>
>
>
---

PGP / GPG Key:  http://www.ncpro.com/GPG/mmweber-at-ncpro-com.asc

Re: [OT] Really need Comments! very strange bug that happens only on Linux.

[Randal L. Schwartz]

> "Vlad" == Vlad Safronov <[EMAIL PROTECTED]> writes:

Vlad> "3238200"? The answer is NO! Try this example on your Linux box

Vlad> ResultSum = 1;
Vlad> Sum = 323.82;

Vlad> the Buffer value is very strange! I have no ideas how Buffer can be 3238199!
Vlad> FreeBSD (old 3.x) works well and Buffer=3238200 as it should be, but on
Vlad> Linux 6.2, 7.0 it is 3238199..

Vlad> Any ideas?

Yes.  Learn that 1/10 doesn't have a precise representation in binary,
so *all* floating point numbers are "approximate".

Perhaps you've just not gotten bitten before.  Welcome to adulthood. :)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

[OT] Really need Comments! very strange bug that happens only on Linux.

[Vlad Safronov]

Hi,

While testing my perl scripts I found a strange bug that happens only on
Linux (RH 6.2, 7.0),
See the code below. Before your read the all text, tell me what's the Buffer
value?
"3238200"? The answer is NO! Try this example on your Linux box

SOURCE test.c:
-=-=-=-=
#include 
#include 

main () {
double Sum, ResultSum;
ResultSum = 1;
Sum = 323.82;
char *Buffer = new char[255];
sprintf(Buffer, "%d", (long)(Sum * ResultSum));
printf("Buffer = [%s], Sum = %.4f, Sum * Result = %.4f\n", Buffer, Sum, (Sum
* ResultSum));

return 0;
}

RESULTS
-=-=-=-=
now compile on Linux RedHat 6.2 with gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)
Output:
$ g++ test.c
$ ./a.out
Buffer = [3238199], Sum = 323.8200, Sum * Result = 3238200.
-=-=-=-=

the Buffer value is very strange! I have no ideas how Buffer can be 3238199!
FreeBSD (old 3.x) works well and Buffer=3238200 as it should be, but on
Linux 6.2, 7.0 it is 3238199..

Any ideas?

/Vlad

[OT] Apache Config Problem

[Robert Landrum]

I'm trying to do something really simple and trying to avoid writing 
an Modperl handler to do it.

We have a website behind a bigip running on port 8080.  When someone 
requests a URL that doesn't end with a slash, it's redirected to 
http://host:8080/path/ .  I tried turning off UseCononicalName, but 
it didn't have any effect.

Any suggestions?

Thanks,

Rob

--
When I used a Mac, they laughed because I had no command prompt. When 
I used Linux, they laughed because I had no GUI.  

Re: Session refresh philosophy

[Rob Nagler]

Perrin Harkins writes:
> Actually, even this stuff could be put into a normalized "sessions" table
> rather than serialized to a blob with Storable.  It just means more work if
> you ever change what's stored in the session.

This is a tough question.  If you store it in a blob, you can't query
it with an ad hoc SQL query.  If you store it in a table, you have to
deal with data evolution.  On the whole, I vote for tables over blobs.
My reasoning is that you have to deal with data evolution anyway.  We
have had about 200 schema changes in the last two years, and very few
of them have had anything to do with user/visitor state.

Rob

Re: Session refresh philosophy

[Perrin Harkins]

> In that the general idea of expiration is to discard
> information that hasn't been accessed in a while, some feel that updating
the
> timestamp is best done during both loading and storing.

If you don't always store the session (Apache::Session doesn't store unless
you modify data in the session) then you have to update the timestamp on
load to be accurate.  If you want to be frugal, you might make the store
operation update the timestamp, and then install a cleanup handler that will
update the timestamp only if the session was not stored.

- Perrin

Re: Session refresh philosophy

[Perrin Harkins]

> As I understand it, the session data is "state" which is committed to
> the database on each request (possibly).  It would seem to me that
> instead of denormalizing the state into a separate session table, you
> should just store it in a normal table.

The typical breakdown I use for this is to put simple state information that
connects this browser to long-term data in the session, and everything else
in normal database tables.  So, I put the user's ID (if this session belongs
to an identified user), a flag telling whether or not this user has given a
secure login so far in this session, and not much else in the session.

Actually, even this stuff could be put into a normalized "sessions" table
rather than serialized to a blob with Storable.  It just means more work if
you ever change what's stored in the session.

- Perrin

Re: Session refresh philosophy

[Rob Nagler]

Milo Hyson writes:
> shopping-cart-style application (whereby someone selects/configures multiple 
> items before they're ultimately committed to a database) how else would you 
> do it? There has to be some semi-persistent (i.e. inter-request) data where 
> selections are stored before they're confirmed.

As I understand it, the session data is "state" which is committed to
the database on each request (possibly).  It would seem to me that
instead of denomalizing the state into a separate session table, you
should just store it in a normal table.  If the data needs to be
expired, then it can be time stamped when it is written.

The point is that it's always simpler to use the existing tables
directly rather than making a copy and storing it in the database
somewhere else.  This usually reduces the code by half or more,
because you don't have to worry about making the copy in the first
place.  Simpler code is more reliable and usually runs faster.

To me, sessions are negativist.  My expectation is that users will end
up clicking OK (making the purchase).  If that is the case, you are
much better off putting the data were belongs right from start.  You
may bind it to an ephemeral entity, such as a shopping cart, but when
the order is complete the only thing you have to do is free the cart
and replace it with an order.  The items, amounts, and special
considerations have already been stored.

If most of your users are filling shopping baskets and walking away
from them, it may be a problem with the software.  Checkout
http://www.useit.com for some ideas on how to improve the ratio.

Often you can avoid any server side persistence by using hidden fields
in the forms.  We use this technique extensively, and we have
encapsulated it so that it is easy to use.  For example, you might
have a sub form which asks the user to fill in an address.  When the
user clicks on the "fill in address" button, the server squirrels away
the context of the current form in the hidden fields of the address
form.  When the user clicks OK on the address form, the fields are
stuffed back into the original form including the new address.

If you have a performance problem, solve it when you can measure it.
Sessions can mitigate performance problems, but so can intelligent
caching, which avoids statefulness in the client-server protocol.

Rob

P.S. For sample sessionless sites, visit http://www.bivio.com and
 http://petshop.bivio.biz (which runs on a 3 year old 300mhz box
 running Apache and Postgres).

Re: [OT] RE: Installing Perl::Magick

[Steve Werby]

"Jonathan M. Hollin" <[EMAIL PROTECTED]> wrote:
> I appreciate that.  This is part of a mod_perl project, however I forgot
> to include "[OT]" in the subject line.  The only reason I post here is
> that the quality of help, and accuracy of reply that I have experienced
> in the past is exactly what I need to get over my initial Linux
> confusion.  However, if anyone knows of a _good_ Linux list...

isp-linux?  See http://isp-lists.isp-planet.com/isp-linux/ for mailing list
subscription.  The ImageMagick mailing list, magick-users is also problably
a good resource for your problem.
mailto:[EMAIL PROTECTED]?subject=subscribe   Both lists
are what I consider medium volume.

You may also want to check for a list related to your Linux distro.  A good
place to find archives of hundreds of mailing lists which have a nice search
interface is http://marc.theaimsgroup.com/.

HTH,

--
Steve Werby
President, Befriend Internet Services LLC
http://www.befriend.com/

RE: Installing Perl::Magick

[Jonathan M. Hollin]

:: I don't know anything about your problem. I just wanted to 
:: give you a 
:: hint, as you said, that you were a complete linux newbie:
:: 
:: Do not work as root. It is dangerous! The root account should be for 
:: installation, configuration of the system and where it cannot be 
:: avoided. I always have some regular user account for working on my 
:: servers and as soon that I want to change something I do a "su". The 
:: best is even to disable root logins on the console and 
:: especially via 
:: ssh / telnet. It gives you some extra security as everyone 
:: knows, that 
:: there must be a root account on a unix box.

Marcel, I was working as root after an "su" as I couldn't install
Image::Magick under my own account.

As far as security goes - I /think/ I have configured my box with only
the www and ssh services available, everything else is locked down (he
says, hopefully).  
 
:: Best regards and enjoy linux!

Thank you.  So far I'm enjoying Linux tremendously.  It's really
challenging, but fun and intellectually stimulating.  I only wish I'd
started years ago.


Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/ 

[OT] RE: Installing Perl::Magick

[Jonathan M. Hollin]

:: Your question isn't a modperl question.  Please keep that in 
:: mind when posting to this list.  Maybe you're trying to use 
:: Perl::Magick as part of a project that uses modperl, but 
:: that doesn't make this a modperl issue.

I appreciate that.  This is part of a mod_perl project, however I forgot
to include "[OT]" in the subject line.  The only reason I post here is
that the quality of help, and accuracy of reply that I have experienced
in the past is exactly what I need to get over my initial Linux
confusion.  However, if anyone knows of a _good_ Linux list...

:: Immediately above is the problem.  The file "magick/api.h" 
:: isn't installed. You may have Imagemagick installed, but you 
:: don't have the development files associated with it installed.

OK.

:: Most package-based Linux distributions, like RedHat (or 
:: RedHat/RPM based
:: systems) or Debian (or Debian/DEB based systems) "split up" 
:: a whole package into parts.  You probably don't have the 
:: "FOO-dev" or "libFOO" package that goes along with FOO.

And it's RedHat I'm using.

:: Maybe you use a RPM-based system... check out 
:: http://rpmfind.net/ in order to track down which :: package 
:: contains the file you need.

http://rpmfind.net/ has already become my best friend!  :-)

Thank you.


Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/ 

Re: "Streaming" compression of output from mod_perl handler?

[Jeffrey W. Baker]

On Tue, 2002-02-19 at 06:11, Igor Sysoev wrote:
> On Tue, 19 Feb 2002, [iso-8859-1] Nicholas Oxhøj wrote:
> 
> > > if mod_deflate will receive flush request it will flush 
> > > deflate encoding
> > > and will write compressed content to Apache buffer. But it does not
> > > flush Apache. Anyway the max block is 8K, Apache buffer is 4K and OS
> > > usually should send data if in OS's buffer there is more then 2K.
> > > So it's probably MSIE feature as well as NC4 can not render tables
> > > until it receive ''.
> > 
> > If it was a "bug" in MSIE, it must be something specifically related to receiving 
>compressed content, since the same data sent uncompressed, gets rendered as they 
>arrive.
> > 
> > Anyway, I just tried getting the same data using lynx, and this made it evident 
>that *without* mod_deflate, the data gets sent by Apache as they are ready, whereas 
>*with* mod_deflate, all the compressed data are sent as one big block at the end.
> 
> I'm not sure that lynx can handle compressed response on the fly -
> it uses gzip in pipe.
> The best way to test it using netcat.
> 
> > So it seems that I am still unable to get the functionality I am looking for.
> 
> I you like to test I can make patch for mod_deflate to flush Apache.
> But if major browsers can not handle compressed content on the fly
> it's not valueable.

I did some experiments using Ethereal to capture the IP stream between
my browser and rambler.ru.  On an example request, the timing was:

0.000 Initiate connection
0.245 Acknowledge connection
0.245 Request sent
0.530 Response receieved
0.540 Response continued
0.823 Response continued
0.826 Response finished

It is difficult to tell from these timings whether the response was sent
in steps or not.  A useful test script would do something like 

for 50 times:
sleep one second;
print 1KB;

-jwb

Re: A really strange POST problem

[Thomas Eibner]

On Tue, Feb 19, 2002 at 10:47:51AM +0100, Tomas Eriksson wrote:
> Hi.
> 
> I'm not sure if this a modperl problem but I'm using modperl (5.005), Apache (1.3) 
>under 
> Debian on my website. 
> 
> Using read(STDIN, $ENV{...}, $buffer) to retrieve the post data. At several places 
>i'm using
> forms with radio buttons from -2 to 2, but from some of my visitors I got almost 
>randomly
> numbers in the form data xxx=13 xxx=4 etc from the radio buttons. I can read these 
>wrong 
> values directly in the $buffer string. This happen often if they post many times but 
>seems 
> to be to other visitors also.  
> 
> I hope I'm not the only one in the world that has this problem...

Please use CGI.pm, Apache::Request, or something else other than rolling
your own solution for reading the CGI data - it will save you time in the
long run.

If it was a bug you'd have to be more specific as to which versions you
are running of Apache/mod_perl.

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  

Re: A really strange POST problem

[Tomas Eriksson]

Yes i'm using strict and it's the string directly from the STDIN. And it's a value 
that don't exist in the radio selection.

like
my $buffer = '';
read(STDIN, $buffer, $ENV{CONTENT_LENGTH});

This can maybe instead be a terrible bug from Microsoft latest browser or something 
but I don't hope so :/

/Tomas
 

- Original Message - 
From: "Oscar Serrano" <[EMAIL PROTECTED]>
To: "Tomas Eriksson" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, February 19, 2002 3:05 PM
Subject: Re: A really strange POST problem


> At 10:47 19/02/2002 +0100, Tomas Eriksson wrote: 
> >
> > Hi.
> >  
> > I'm not sure if this a modperl problem but I'm using modperl (5.005), Apache
> > (1.3) under 
> > Debian on my website. 
> >  
> > Using read(STDIN, $ENV{...}, $buffer) to retrieve the post data. At several
> > places i'm using
> > forms with radio buttons from -2 to 2, but from some of my visitors I got
> > almost randomly
> > numbers in the form data xxx=13 xxx=4 etc from the radio buttons. I can read
> > these wrong 
> > values directly in the $buffer string. This happen often if they post many
> > times but seems 
> > to be to other visitors also.  
> >  
> 
> 
> 
> Ummm, not sure, but that seems to be the classical problem of not initialicing
> the variables at the beggining of the script. Mod_perl mantains a copy of the
> value and each time you submit you add the new value to the existing value.
> You
> are getting different values each time, depending of the httpd child that
> serves the script.
> Are you using strict (use strict) at the beggining of the script?
> 
> Oscar Serrano.
> 
> 
> 
> >
> > I hope I'm not the only one in the world that has this problem...
> >  
> > kind regards
> > Tomas
> 
> 
> 
> 
> 

Re: "Streaming" compression of output from mod_perl handler?

[Igor Sysoev]

On Tue, 19 Feb 2002, [iso-8859-1] Nicholas Oxhøj wrote:

> > if mod_deflate will receive flush request it will flush 
> > deflate encoding
> > and will write compressed content to Apache buffer. But it does not
> > flush Apache. Anyway the max block is 8K, Apache buffer is 4K and OS
> > usually should send data if in OS's buffer there is more then 2K.
> > So it's probably MSIE feature as well as NC4 can not render tables
> > until it receive ''.
> 
> If it was a "bug" in MSIE, it must be something specifically related to receiving 
>compressed content, since the same data sent uncompressed, gets rendered as they 
>arrive.
> 
> Anyway, I just tried getting the same data using lynx, and this made it evident that 
>*without* mod_deflate, the data gets sent by Apache as they are ready, whereas *with* 
>mod_deflate, all the compressed data are sent as one big block at the end.

I'm not sure that lynx can handle compressed response on the fly -
it uses gzip in pipe.
The best way to test it using netcat.

> So it seems that I am still unable to get the functionality I am looking for.

I you like to test I can make patch for mod_deflate to flush Apache.
But if major browsers can not handle compressed content on the fly
it's not valueable.

Igor Sysoev

Re: Installing Perl::Magick

[Richard Dice]

Your question isn't a modperl question.  Please keep that in mind when
posting to this list.  Maybe you're trying to use Perl::Magick as part
of a project that uses modperl, but that doesn't make this a modperl
issue.

> I'm not quite ready to give up on this yet.  Below is a screen grab of my 
> attempt(s) to install Perl::Magick.  As I have said previously, I am a 
> complete Linux newbie - so what's happening here is lost on me (as yet).
> 
> Image::Magick is installed.  What am I doing wrong?
[deletia]
> RSION=\"5.41\" -DXS_VERSION=\"5.41\" -fpic 
> -I/usr/local/lib/perl5/5.6.1/i686-lin
> ux/CORE -DHAVE_CONFIG_H Magick.c
> Magick.xs:76:24: magick/api.h: No such file or directory
> make: *** [Magick.o] Error 1

Immediately above is the problem.  The file "magick/api.h" isn't installed.
You may have Imagemagick installed, but you don't have the development
files associated with it installed.

Most package-based Linux distributions, like RedHat (or RedHat/RPM based
systems) or Debian (or Debian/DEB based systems) "split up" a whole package
into parts.  You probably don't have the "FOO-dev" or "libFOO" package
that goes along with FOO.

I use Debian... here's what I have that pertains to your query re:
ImageMagick...

rdice@tanru:~$ export COLUMNS=120 && dpkg --list | grep -i image
ii  imagemagick  5.4.2.3-1Image manipulation programs.
ii  libmagick++5 5.4.2.3-1The object-oriented C++ API to 
the ImageMagick library
ii  libmagick++5-dev 5.4.2.3-1The object-oriented C++ API to 
the ImageMagick library.--develop
ii  libmagick5   5.4.2.3-1Image manipulation library (free 
version).

(The above list edited to remove matches that don't have anything to do with
ImageMagick.)

Maybe you use a RPM-based system... check out http://rpmfind.net/ in order
to track down which package contains the file you need.

Cheers,
Richard
-- 

  Richard Dice * Personal 416 841 7365 * Fax 416 841 7364
  ShadNet Creator * http://shadnet.shad.ca/ * [EMAIL PROTECTED]
  Occasional Writer, HotWired * http://www.hotwired.com/webmonkey/
  "squeeze the world 'til it's small enough to join us heel to toe"
  - jesus jones

Re: Installing Perl::Magick

[Marcel Weber]

Hi

I don't know anything about your problem. I just wanted to give you a 
hint, as you said, that you were a complete linux newbie:

Do not work as root. It is dangerous! The root account should be for 
installation, configuration of the system and where it cannot be 
avoided. I always have some regular user account for working on my 
servers and as soon that I want to change something I do a "su". The 
best is even to disable root logins on the console and especially via 
ssh / telnet. It gives you some extra security as everyone knows, that 
there must be a root account on a unix box.

Best regards and enjoy linux!

Marcel



Am Dienstag den, 19. Februar 2002, um 13:03, schrieb lamp:

> I'm not quite ready to give up on this yet.  Below is a screen grab of 
> my
> attempt(s) to install Perl::Magick.  As I have said previously, I am a
> complete Linux newbie - so what's happening here is lost on me (as yet).
>
> Image::Magick is installed.  What am I doing wrong?
>
---

PGP / GPG Key:  http://www.ncpro.com/GPG/mmweber-at-ncpro-com.asc

Re: A really strange POST problem

[Oscar Serrano]

At 10:47 19/02/2002 +0100, Tomas Eriksson wrote: 
>
> Hi.
>  
> I'm not sure if this a modperl problem but I'm using modperl (5.005), Apache
> (1.3) under 
> Debian on my website. 
>  
> Using read(STDIN, $ENV{...}, $buffer) to retrieve the post data. At several
> places i'm using
> forms with radio buttons from -2 to 2, but from some of my visitors I got
> almost randomly
> numbers in the form data xxx=13 xxx=4 etc from the radio buttons. I can read
> these wrong 
> values directly in the $buffer string. This happen often if they post many
> times but seems 
> to be to other visitors also.  
>  



Ummm, not sure, but that seems to be the classical problem of not initialicing
the variables at the beggining of the script. Mod_perl mantains a copy of the
value and each time you submit you add the new value to the existing value.
You
are getting different values each time, depending of the httpd child that
serves the script.
Are you using strict (use strict) at the beggining of the script?

Oscar Serrano.



>
> I hope I'm not the only one in the world that has this problem...
>  
> kind regards
> Tomas

A really strange POST problem

[Tomas Eriksson]

Hi.
 
I'm not sure if this a modperl problem but I'm 
using modperl (5.005), Apache (1.3) under 
Debian on my website. 
 
Using read(STDIN, $ENV{...}, $buffer) to retrieve 
the post data. At several places i'm using
forms with radio buttons from -2 to 2, but 
from some of my visitors I got almost randomly
numbers in the form data xxx=13 xxx=4 etc from the 
radio buttons. I can read these wrong 
values directly in 
the $buffer string. This happen often if 
they post many times but seems 
to be to other visitors also.  
 
I hope I'm not the only one in the world that has 
this problem...
 
kind regards
Tomas

Authenticating against Active Directory

[Stephen Reppucci]

Does anyone have any experience in writing an authentication handler
that authenticates against Microsoft's Active Directory?

I have a project for a client who wants to use their existing AD
data for user data (username, password, realname, groups, etc).  In
doing a little googling, it seems that AD is "sort of like" LDAP,
but I couldn't find any definitive info that something like
Apache::AuthenLDAP will just work against AD. (The Apache server
piece would be Linux, if that matters...)

(I saw the recent O'Reilly article on doing AD integration, but that
seemed to rely on deploying a proxy process on the AD server, which
I'd like to avoid, if possible.)

Thanks for any insight anyone can add.

-- 
Steve Reppucci   [EMAIL PROTECTED] |
Logical Choice Software  http://logsoft.com/ |
=-=-=-=-=-=-=-=-=-=-  My God!  What have I done?  -=-=-=-=-=-=-=-=-=-=

Re: "Streaming" compression of output from mod_perl handler?

[Nicholas Oxhøj]

> if mod_deflate will receive flush request it will flush 
> deflate encoding
> and will write compressed content to Apache buffer. But it does not
> flush Apache. Anyway the max block is 8K, Apache buffer is 4K and OS
> usually should send data if in OS's buffer there is more then 2K.
> So it's probably MSIE feature as well as NC4 can not render tables
> until it receive ''.

If it was a "bug" in MSIE, it must be something specifically related to receiving 
compressed content, since the same data sent uncompressed, gets rendered as they 
arrive.

Anyway, I just tried getting the same data using lynx, and this made it evident that 
*without* mod_deflate, the data gets sent by Apache as they are ready, whereas *with* 
mod_deflate, all the compressed data are sent as one big block at the end.

So it seems that I am still unable to get the functionality I am looking for.

Nicholas Oxhøj

Installing Perl::Magick

[lamp]

I'm not quite ready to give up on this yet.  Below is a screen grab of my 
attempt(s) to install Perl::Magick.  As I have said previously, I am a 
complete Linux newbie - so what's happening here is lost on me (as yet).

Image::Magick is installed.  What am I doing wrong?

Thanks in advance.


[root@Beverley-II PerlMagick]# perl Makefile.PL
Checking if your kit is complete...
Looks good
Note (probably harmless): No library found for -ljasper
Writing Makefile for Image::Magick
[root@Beverley-II PerlMagick]# make test
cp Magick.pm blib/lib/Image/Magick.pm
AutoSplitting blib/lib/Image/Magick.pm (blib/lib/auto/Image/Magick)
/usr/local/bin/perl -I/usr/local/lib/perl5/5.6.1/i686-linux 
-I/usr/local/lib/per
l5/5.6.1 /usr/local/lib/perl5/5.6.1/ExtUtils/xsubpp  -typemap 
/usr/local/lib/per
l5/5.6.1/ExtUtils/typemap Magick.xs > Magick.xsc && mv Magick.xsc Magick.c
cc -c -I../ -I.. -I/usr/include/freetype2 -D_REENTRANT 
-D_FILE_OFFSET_BITS=64 -I
/usr/local/include -I/usr/X11R6/include -I/usr/X11R6/include/X11 
-fno-strict-ali
asing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2   
-DVE
RSION=\"5.41\" -DXS_VERSION=\"5.41\" -fpic 
-I/usr/local/lib/perl5/5.6.1/i686-lin
ux/CORE -DHAVE_CONFIG_H Magick.c
Magick.xs:76:24: magick/api.h: No such file or directory
make: *** [Magick.o] Error 1
[root@Beverley-II PerlMagick]# mak install
bash: mak: command not found
[root@Beverley-II PerlMagick]# make install
cc -c -I../ -I.. -I/usr/include/freetype2 -D_REENTRANT 
-D_FILE_OFFSET_BITS=64 -I
/usr/local/include -I/usr/X11R6/include -I/usr/X11R6/include/X11 
-fno-strict-ali
asing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2   
-DVE
RSION=\"5.41\" -DXS_VERSION=\"5.41\" -fpic 
-I/usr/local/lib/perl5/5.6.1/i686-lin
ux/CORE -DHAVE_CONFIG_H Magick.c
Magick.xs:76:24: magick/api.h: No such file or directory
make: *** [Magick.o] Error 1

Re: "Streaming" compression of output from mod_perl handler?

[Igor Sysoev]

On Tue, 19 Feb 2002, [iso-8859-1] Nicholas Oxhøj wrote:

> > What mod_deflate did you try ? My or Apache 2.0 ?
> Yours
> 
> > I can comment my mod_deflate.
> > First, mod_deflate did not collect all output before compressing - it
> > compress it on the fly. But it emits compressed content in 8K block.
> > It's Apache's HUGE_STRING_LEN #define and it can be changed 
> > in sources.
> > Besides if some module flushes output then mod_deflate would 
> > flushed it too.
> > 
> > mod_deflate did not have problems with chunked transfer-encoding
> > because it compress content before Apache start to make chunks.
> > mod_deflate remove Content-Length header so compressed content
> > would be sent to client chunked (HTTP/1.1) or not (HTTP/1.0).
> 
> At the moment I have made my mod_perl handler extra slow, so that it is easier to 
>see the effects of the different compression modules.
> The handler returns approx. 430KB of uncompressed HTML.
> 
> With no compression module, the HTML slowly trickles to the browser, and the data 
>gets displayed/rendered as it arrives.
> With mod_deflate enabled, nothing gets displayed in the browser until all 24KB of 
>the gzip compressed HTML has arrived at the browser.
> 
> Unfortunately I don't really have the tools to see when data are received at the 
>client side, I can only judge by the time they are displayed/rendered in the browser. 
>So I can't really tell if the problem is, that all the data are received in one big 
>batch or if they are actually received in 8K blocks, but some bug-like feature in IE 
>5.5 makes it unable to decode the gzipped data in a "streaming" fashion as they 
>arrive.

Sorry,

if mod_deflate will receive flush request it will flush deflate encoding
and will write compressed content to Apache buffer. But it does not
flush Apache. Anyway the max block is 8K, Apache buffer is 4K and OS
usually should send data if in OS's buffer there is more then 2K.
So it's probably MSIE feature as well as NC4 can not render tables
until it receive ''.

Igor Sysoev

Re: [OT-ish] Session refresh philosophy

[Ged Haywood]

Hi there,

On Mon, 18 Feb 2002, Milo Hyson wrote:

> maybe I'm just approaching the problem incorrectly. If one is doing a 
> shopping-cart-style application (whereby someone selects/configures multiple 
> items before they're ultimately committed to a database) how else would you 
> do it? There has to be some semi-persistent (i.e. inter-request) data where 
> selections are stored before they're confirmed.

You can for example send a hidden  object back and forth between
your Client and the app.

73,
Ged.

Re: "Streaming" compression of output from mod_perl handler?

[Nicholas Oxhøj]

> What mod_deflate did you try ? My or Apache 2.0 ?
Yours

> I can comment my mod_deflate.
> First, mod_deflate did not collect all output before compressing - it
> compress it on the fly. But it emits compressed content in 8K block.
> It's Apache's HUGE_STRING_LEN #define and it can be changed 
> in sources.
> Besides if some module flushes output then mod_deflate would 
> flushed it too.
> 
> mod_deflate did not have problems with chunked transfer-encoding
> because it compress content before Apache start to make chunks.
> mod_deflate remove Content-Length header so compressed content
> would be sent to client chunked (HTTP/1.1) or not (HTTP/1.0).

At the moment I have made my mod_perl handler extra slow, so that it is easier to see 
the effects of the different compression modules.
The handler returns approx. 430KB of uncompressed HTML.

With no compression module, the HTML slowly trickles to the browser, and the data gets 
displayed/rendered as it arrives.
With mod_deflate enabled, nothing gets displayed in the browser until all 24KB of the 
gzip compressed HTML has arrived at the browser.

Unfortunately I don't really have the tools to see when data are received at the 
client side, I can only judge by the time they are displayed/rendered in the browser. 
So I can't really tell if the problem is, that all the data are received in one big 
batch or if they are actually received in 8K blocks, but some bug-like feature in IE 
5.5 makes it unable to decode the gzipped data in a "streaming" fashion as they arrive.

Nicholas Oxhøj

Re: "Streaming" compression of output from mod_perl handler?

[Igor Sysoev]

On Tue, 19 Feb 2002, [iso-8859-1] Nicholas Oxhøj wrote:

> I am looking for an Apache module which will allow me to compress the output of my 
>mod_perl handler (a "native" handler, i.e. not running under Apache::Registry). But 
>since my handler can potentially take a long time to finish, the output has to be 
>compressed in a "streaming" fashion (or in small blocks) so that the browser will 
>start receiving data before my handler has completely finished. 
> 
> I have been experimenting with all the different Apache compression modules I have 
>been able to find, but have not been able to get the desired result. I have tried 
>Apache::GzipChain, Apache::Compress, mod_gzip and mod_deflate, with different 
>results. One I cannot get to work at all. Most work, but seem to collect all the 
>output before compressing it and sending it to the browser.
> 
> There also seems to be an issue about the new HTTP/1.1 "chunked" transfer-encoding. 
>For instance, mod_gzip will not compress chunked output, unless you allow it to 
>"dechunk" it by collecting all the output and compressing it as one big block.
> 
> So I am basically looking for anyone who has had any success in achieving this kind 
>of "streaming" compression, who could direct me at an appropriate Apache module.

What mod_deflate did you try ? My or Apache 2.0 ?
I can comment my mod_deflate.
First, mod_deflate did not collect all output before compressing - it
compress it on the fly. But it emits compressed content in 8K block.
It's Apache's HUGE_STRING_LEN #define and it can be changed in sources.
Besides if some module flushes output then mod_deflate would flushed it too.

mod_deflate did not have problems with chunked transfer-encoding
because it compress content before Apache start to make chunks.
mod_deflate remove Content-Length header so compressed content
would be sent to client chunked (HTTP/1.1) or not (HTTP/1.0).

Igor Sysoev

Re: mod_perl, mod_gzip, incredible suckage

[Igor Sysoev]

On Tue, 19 Feb 2002, Eric Cholet wrote:

> --On vendredi 15 février 2002 17:19 +0300 Igor Sysoev <[EMAIL PROTECTED]> 
> wrote:
> 
> > You can try
> > ftp://ftp.lexa.ru/pub/apache-rus/contrib/mod_deflate-1.0.11.tar.gz
> >
> > It compresses content on the fly without any temporary files
> > as mod_gzip does. It has workarounds with buggy browsers.
> > mod_gzip has not.
> >
> > Drawbacks:
> > It patches Apache and can not be loaded as DSO.
> > It compresses static files every time. mod_gzip can use cached
> > compressed file.
> > It has Russian documentation only but you can ask me if you
> > have any problems.
> 
> Yeah, can you translate that little paragraph about FreeBSD?

There are 3 times when FreeBSD is referred:


in /.configure:
--with-idle-check - check CPU idle state. This parameter is available
on FreeBSD 3.x and above only.


DeflateIdleCheck:

Syntax: DeflateIdleCheck number
Default: DeflateIdleCheck 1
Context: server config

Set interval for CPU idle checking in seconds.
This directive is available on FreeBSD 3.x and above only if you
set --with-idle-check configure parameter.


DeflateMinIdle:

Syntax: DeflateMinIdle 0 .. 100
Default: DeflateMinIdle 0
Context: server config

Set minumal CPU idle level in percent when compressing is enabled.
This directive is available on FreeBSD 3.x and above only if you
set --with-idle-check configure parameter.


Small comment. We are using idle checking on www.rambler.ru but it seems
it is not usefull on small files (<50K) and modern CPU.

Igor Sysoev

Re: mod_perl, mod_gzip, incredible suckage

[Eric Cholet]

--On vendredi 15 février 2002 17:19 +0300 Igor Sysoev <[EMAIL PROTECTED]> 
wrote:

> You can try
> ftp://ftp.lexa.ru/pub/apache-rus/contrib/mod_deflate-1.0.11.tar.gz
>
> It compresses content on the fly without any temporary files
> as mod_gzip does. It has workarounds with buggy browsers.
> mod_gzip has not.
>
> Drawbacks:
> It patches Apache and can not be loaded as DSO.
> It compresses static files every time. mod_gzip can use cached
> compressed file.
> It has Russian documentation only but you can ask me if you
> have any problems.

Yeah, can you translate that little paragraph about FreeBSD?

--
Eric Cholet