Closed
Bug 266443
Opened 20 years ago
Closed 17 years ago
token.cgi error processing forgotten-password.txt.tmpl with unicode data
Categories
(Bugzilla :: User Accounts, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: m_alsebaeyie, Unassigned)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10.1 Build Identifier: For the purpose of the Arabic Localiztion of Bugzilla, I have converted all pages to UTF-8 I overcame the unicode problem (Bug 126266) by adding the MIME-TYPE, Content-Type and Content-Transfer-Encoding headers in the templates for the email and the parameters page (as needed) However, one function, which sends a token to the user for changing his password, doesn't work. This occurs when variables.none.tmpl is converted into unicode, when it gets used in forgotten-password.txt.tmpl a ' No Recipient address found in header' error is thrown by apache when token.cgi is processing. This Happens before invoking sendmail and after the token is inserted into the database. Reproducible: Always Steps to Reproduce: 1.Convert variables.none.tmpl to unicode (I tried with forgotten-password.txt.tmpl as unicode and as normal latin 1) 2.run ./checksetup.pl to compile templates 3.request a change password token
| Reporter | ||
Updated•20 years ago
|
Version: unspecified → 2.18
Comment 1•20 years ago
|
||
"No recipient address found in header" is an error generated by Sendmail, so this by definition can't be happening prior to Sendmail getting invoked. Are you MIME-encoding the header lines that contain non-ASCII data?
| Reporter | ||
Comment 2•20 years ago
|
||
I assumed that sendmail has not been invoked since I found no errors in sendmail log. I removed all references to non-ASCII data from the header and the problem still occurs. This problem only happens in one place (that I know of) which is sending tokens. Normal bug emails contain unicode data in both the subject and the body and they are processed ok.
Updated•19 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Updated•18 years ago
|
Assignee: myk → user-accounts
Comment 3•17 years ago
|
||
This should be working much better in Bugzilla 3.0, which has much better utf-8 support.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•