Re: UTF8 character issue with Apache::Request?

2002-09-28 Thread Joe Schaefer

[EMAIL PROTECTED] writes:

[...]

 With Kanji filename :
 Size is 0
 UPL:Content-Disposition=form-data; name=UPLOADFILE; 
 filename=.DOC
 UPL:Content-Type=application/octet-stream
 
 Without Kanji filename
 Size is 306688
 UPL:Content-Disposition=form-data; name=UPLOADFILE; 
 filename=copy.DOC
 UPL:Content-Type=application/msword
 
 Any thoughts or input would be great.

Are you certain this is a server-side problem?  The 
varying Content-Types look suspicious to me.  I'd double-check
(via tcpdump or something) that the client is actually sending 
the whole file to the server.

-- 
Joe Schaefer



CGI Forms Problems (Getting Old Params)

2002-09-28 Thread Shannon Appelcline

Yesterday I ported a few thousand lines of code I'd been working on 
over to Perl. It was quite a bit of work getting all of the strict 
stuff correct and then fighting with the modules-do-not-reload 
problem, but it's now mostly dealt with, and my code's much cleaner 
and more modularized. (Huzzah.)

Unfortunately I've been continuing to have one program that I can't 
figure out. Somehow, my information being submitted through forms 
sometimes reverts to old data after I've clicked Submit and before 
it's processed.

Now, I've read through much of the mod_perl documents, FAQs, etc., 
and I understand the general shape of *why* this happens. It's the 
result of mod_perl keeping the perl modules, and thus the variables, 
in memory. When I hit a server that's already been loaded, I get 
incorrect results. What I don't understand is *how* it's happening in 
this specific case, because I'm being very careful about clearly 
setting my variables each time through.

There must be some aspect of how mod_perl works that I'm missing. I'm 
hoping someone here can (1) tell me what I'm doing wrong in this 
specific case and (2) tell me where my mental map is incorrect.

Anyway, here we go.

I start off with a simple index.cgi that I've made extremely short to 
avoid the issue of nested subroutines. It has a require:

--
$main::filePath = /var/www/skotos/myskotos;
require ${main::filePath}/modules/lib/mylib.pm;
--

 From that required library, I set my $cgi variable:

--
package mylib;

use CGI;
use CGI::Pretty qw( :html3 );

$mylib::cgi = new CGI;
--

It's a global variable, but that seems entirely appropriate for 
something that's used in nearly every function. And, it gets 
explicitly set every time the program is run.

Back in the original index.cgi, I have the problems when it's called 
to process form information. Here's that particular segment of code:

--
 require ${main::filePath}/modules/web/myedit.pm;

 my $action = $mylib::cgi-param('action');

 $main::pageNumber = $mylib::cgi-param('pageNumber');
 $main::contentType = $mylib::cgi-param('contentType');

 if ($action eq editpage) {
 myedit::ProcessEditPage();
 } elsif ($action eq editcontent) {
 myedit::ProcessEditContent();
 }
--

And, pretty much ANY of those parameters that I call in from $cgi can 
come up wrong. Both the local variables defined by my ($action) and 
the global variables set to $main ($pageNumber, $contentType) ... 
which tells me that the problem is back in that $cgi reference.

But why?

Can I not set variables which might change down in modules? That 
would seem grossly limiting if so, given that I've moved everything 
to modules in order to avoid the nested subroutine problems.

Or am I missing something else?

I should mention, that out of extreme paranoia at this point I'm even 
trying to undef $cgi when I'm done, to no effect.

--
END {
 $mylib::dbh-disconnect if $mylib::dbh;
 undef $mylib::cgi;
}
--

Help?

Shannon


-- 
Shannon
--
You met me at a very strange time in my life. --_Fight Club_




Re: UTF8 character issue with Apache::Request?

2002-09-28 Thread Peter Bi

Please take a serious look. There were several related reports in the
mailing list during the months: Apache::Request might not handle
double-bytes or utf8 correctly. Or it may be due to the C library.

Peter

- Original Message -
From: Joe Schaefer [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; modperl list [EMAIL PROTECTED]
Sent: Saturday, September 28, 2002 10:08 AM
Subject: Re: UTF8 character issue with Apache::Request?


 [EMAIL PROTECTED] writes:

 [...]

  With Kanji filename :
  Size is 0
  UPL:Content-Disposition=form-data; name=UPLOADFILE;
  filename=.DOC
  UPL:Content-Type=application/octet-stream
 
  Without Kanji filename
  Size is 306688
  UPL:Content-Disposition=form-data; name=UPLOADFILE;
  filename=copy.DOC
  UPL:Content-Type=application/msword
 
  Any thoughts or input would be great.

 Are you certain this is a server-side problem?  The
 varying Content-Types look suspicious to me.  I'd double-check
 (via tcpdump or something) that the client is actually sending
 the whole file to the server.

 --
 Joe Schaefer





Re: UTF8 character issue with Apache::Request?

2002-09-28 Thread Joe Schaefer

Peter Bi [EMAIL PROTECTED] writes:

 Please take a serious look. 

I did, and I suspect this problem is caused by OP's client/browser 
failing to open the file with the Kanji filename, so it might be
sending an empty file with the default enctype instead.

 There were several related reports in the mailing list during the
 months: Apache::Request might not handle double-bytes or utf8
 correctly. Or it may be due to the C library.

You seem to know something about this issue.  However, this is the first 
time I've seen utf8 discussed in relation to Apache::Request on this list.
I've tried a few dozen links from google (utf8 Apache::Request), and 
I've searched the epigone archives for this list.  I wasn't able to find 
a single related report.

A reference url, a test case, or a better still, a patch, would be 
considerably more helpful than sending me on a wild goose chase.

-- 
Joe Schaefer