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)

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: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.