> "Peng" == Peng Yonghua writes:
Peng> And, can I override any method from a class via this way? is this a
general
Peng> trick? thanks.
Yes, and your downstream will hate you for it. The ruby people do this
all the time, and it makes their code brittle. I did this in my app,
and would nev
And, can I override any method from a class via this way? is this a
general trick? thanks.
On 2017/6/2 8:48, Peng Yonghua wrote:
good patch. thanks for sharing.
On 2017/6/1 23:34, Randal L. Schwartz wrote:
I realized that I never posted my ultimate solution. I monkey patch
CGI.pm:
require
good patch. thanks for sharing.
On 2017/6/1 23:34, Randal L. Schwartz wrote:
I realized that I never posted my ultimate solution. I monkey patch
CGI.pm:
require CGI;
{
my $orig = \&CGI::param;
no warnings 'redefine';
*CGI::param = sub {
$CGI::LIST_CONTEXT_WARN = 0; # workaround
> "Randal" == Randal L Schwartz writes:
Randal> Getting really frustrated with mod_perl2's apparent inability to
Randal> probably read UTF8 input.
Randal> Here's my mod_perl2 setup:
Randal> Apache 2.2.[something]
Randal> mod_perl 2.0.7 (or nearly that)
Randal> ModPerl::Registry
Randal
apreq validates anything it presents as utf8, otherwise it marks it as ISO88591
or some windows encoding I don't remember the name of if that fails.
On Monday, September 8, 2014 3:17 PM, André Warnier wrote:
Michael Schout wrote:
> On 9/2/14, 4:19 PM, Randal L. Schwartz wrote:
>
>> ##
Michael Schout wrote:
On 9/2/14, 4:19 PM, Randal L. Schwartz wrote:
## ensure utf8 CGI params:
$CGI::PARAM_UTF8 = 1;
Sorry to chime in late on this, but part of the problem with CGI.pm and
UTF-8 is that PARAM_UTF8 gets clobbered by a cleanup handler that CGI.pm
itself registers if its run
On 9/2/14, 4:19 PM, Randal L. Schwartz wrote:
> ## ensure utf8 CGI params:
> $CGI::PARAM_UTF8 = 1;
Sorry to chime in late on this, but part of the problem with CGI.pm and
UTF-8 is that PARAM_UTF8 gets clobbered by a cleanup handler that CGI.pm
itself registers if its running under mod_perl.
> "Randal" == Randal L Schwartz writes:
Randal> Yeah, just coded that. In a BEGIN block in my app, I monkey-patched
Randal> read_from_client:
And then I've also tried to monkey-patch ->read just as you said.
On the first read, an empty string is apparently returned, which fails
something h
> "Torsten" == Torsten Förtsch writes:
Torsten> Though, I wouldn't go this way. I'd either try to force CGI.pm to read
Torsten> from STDIN and use the perl-script handler
Torsten>
(http://perl.apache.org/docs/2.0/user/config/config.html#C_perl_script_). This
Torsten> pushes a PerlIO layer to
On 03/09/14 21:38, Randal L. Schwartz wrote:
> What I need to know is what is mod_perl doing differently? Does it not
> respect binmode STDIN, ":utf8"? Apparently not. So if you know of a
> way to get mod_perl to "fix" reading from the browser properly, I'm
> interested in that.
Something along
I encode a "pound sign" which as a parameter which indicates whether
content is UTF-8, UCS or latin-1 - and this seems to resolve most of the
issues... I did take a lot of effort to fix issues with utf8 and there
are a lot of these - between form -> post; between requests if storing
data in ses
> "André" == André Warnier writes:
André> The methodology I follow is as follows :
André> 1) all html pages of the applications should have a tag like :
André>
André> 2) all in the page should have the attributes
André> enctype="application/form-data"
André> accept-charset="." (the s
On 09/03/2014 11:17 AM, André Warnier wrote:
> 3) all forms contain a hidden text like
> (some known
> sequence of "diacritics" characters guaranteed to have a different byte
> length between ISO-8859-x and UTF-8 encoding)
> [...]
> But it's helped me sleep better for quite a while now.
This i
Hi Randal.
Randal L. Schwartz wrote:
Getting really frustrated with mod_perl2's apparent inability to
probably read UTF8 input.
Here's my mod_perl2 setup:
Apache 2.2.[something]
mod_perl 2.0.7 (or nearly that)
ModPerl::Registry
Perl "script" with CGI.pm
Very early in my app:
## ens
14 matches
Mail list logo
