Closed Bug 266443 Opened 21 years ago Closed 18 years ago

token.cgi error processing forgotten-password.txt.tmpl with unicode data

Categories

(Bugzilla :: User Accounts, defect)

2.18
x86
Linux
defect
Not set
normal

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
Version: unspecified → 2.18
"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?
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.
QA Contact: mattyt-bugzilla → default-qa
Assignee: myk → user-accounts
This should be working much better in Bugzilla 3.0, which has much better utf-8 support.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.