ido50 has asked for the wisdom of the Perl Monks concerning the following question:
Hi again!
I'm using CGI.pm in a new CMS I'm writing using Perl. When creating web pages, even though I supply a character set, CGI.pm ignores it and doesn't create a meta tag for the character set, which causes a default charset ISO-8859-1. I have used the following code:
print $query->header(-charset=>'utf-8'), $query->start_html(-encoding=>'utf-8');
I've tried other charsets, as well as ommitting the encoding from the start_html, nothing seems to work.
Anyone knows why this may happen?
In another problem, I'm also using CGI.om's cookie abilities to store cookies. When a user logins to the program, the program can either remember him (Creates a cookie which expires in 10 years) or not (Creates a cookie which expires in 1 hour). I use Mozilla, and there are no problems. But with Internet Explorer, unless I choose that the program should remember me, the cookie is not stored and immediatly after the login the session is expired and a new login is required.
What can I do? Thanks!
-------------------------
Live fat, die young
Re: Two CGI.pm problems
by saskaqueer (Friar) on Jun 07, 2004 at 21:20 UTC
|
The '-encoding' attribute sets the encoding in the XML declaration, not as a META element. To get that, you'd use this (which is pretty ugly but works):
my $q = CGI->new();
print $q->header(-charset => 'utf-8'),
$q->start_html(
-encoding => 'utf-8',
-head => $q->meta({
-http_equiv => 'Content-Type',
-content => 'text/html; charset=utf-8'
})
);
| [reply] [d/l] |
|
| [reply] |
Re: Two CGI.pm problems
by hardburn (Abbot) on Jun 07, 2004 at 21:09 UTC
|
The IE behavior should be considered a feature. If the user specifically asks not to be remembered, then the cookie should be session-only.
----
send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.
| [reply] |
|
>The IE behavior should be considered a feature.
I believe this answer stems from a complete misunderstanding of the original poster's question.
Doesn't "session-only" mean "until the browser is quit?"
The cookie is not saved until the browser is quit, according to the OP's account. It's lost, in IE, right away, so, not a feature.
I know there are bugs in some versions of IE which require the path to be set, but I don't think that's common-- Mac version 5 only?
Short answer: show us your code, and check out the exact details of the cookie using a browser which allows you do do that.
Does your "log-in successful" page actually check that a cookie has been set? Or does it just assume that it's been set? What are the conditions you check in order to return "log-in successful"?
($_='kkvvttuubbooppuuiiffssqqffssmmiibbddllffss')
=~y~b-v~a-z~s; print
| [reply] |
|
| [reply] |
|
| [reply] |
|
| [reply] |
|
|
Re: Two CGI.pm problems
by CountZero (Bishop) on Jun 07, 2004 at 21:47 UTC
|
If you are on an Apache-server, there are a lot of Session-modules on CPAN such as Apache::Session. They may or may not use cookies in maintaining state, but I learned never to rely on cookies to do that: some users (either deliberately, out of misguided fear or because of company policy) cannot or will not accept cookies and then your whole session management breaks down.
CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law
| [reply] |
Re: Two CGI.pm problems
by iburrell (Chaplain) on Jun 08, 2004 at 20:50 UTC
|
print $query->header(-charset=>'utf-8');
print $query->start_html(-encoding=>'utf-8');
It outputs this:
Content-Type: text/html; charset=utf-8
<?xml version="1.0" encoding="utf-8"?>
It sets the charset in the HTTP header, and the encoding on the XML. It does not add any meta http-equiv tag with the Content-Type, but that is not needed since the Content-Type is set in the header.
What browser is not setting the encoding from the Content-Type?
| [reply] [d/l] [select] |
|
|