Template process failed error prints content-type to browser window.

RESOLVED FIXED in Bugzilla 2.16



Creating/Changing Bugs
17 years ago
5 years ago


(Reporter: CodeMachine, Assigned: myk)


Bugzilla 2.16
Dependency tree / graph


(Whiteboard: [blocker will fix])



17 years ago
When the template process fails on editattachstatuses.cgi (say because of bad
permissions to the template), the content type gets written twice, and it
appears once on the page as a result.


17 years ago
Priority: -- → P5
Target Milestone: --- → Bugzilla 2.16
This is a general problem with all the code we have that makes templates - we
are using DisplayError() to display the error, and it prints its own headers.

Surely the solution here is to move the headers into the template. I've tried
this on query.cgi and it works. We don't want to be sending rdf templates as
text/html anyway.


Comment 2

17 years ago
That's one possible solution.  Another is to have a variable called
$headers_written or something that is checked by DisplayError and such.

Comment 3

17 years ago
No, the solution is not to move the headers into the template, since most web
server interface libraries (our custom hacked one excepted) separate out header
from content generation.  DisplayError generates HTTP headers because it is
intended to be used during logic processing, during which time no content should
have been returned to the user.  We should either modify it in the way Matty
says or create another function for returning errors that occur during content
Or we could use functions to write the headers (WriteHeader("text/html")) and
store the header state in a global variable.

Or have two error functions. I like that better than passing a parameter. If you
want to throw an error half-way through a header, you complete it and then call
the "already done" error handler.

DisplayErrorPage() and DisplayError()?

Summary: Template process failed error drops poop trail. → Template process failed error prints content-type to browser window.
We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18

Comment 6

16 years ago
What if we are generating an XML template and it fails?
Having discussed this with Myk in the newsgroups, I now think we need the
following sorts of error function:

UserError("message"). Prints content type, and uses a template to format the
error message. Called anywhere in any CGIs.

CodeError("message"). Also attempts to use a template, but falls back on a
non-template error message if that fails. Optionally logs info to a file for
diagnosis of bugs.

TemplateError("content-type"). Does not print a content-type, but produces the
correct sort of "template failed" error message for the given content-type. This
should be in the || arm of all template calls.

How does that sound?


Comment 8

16 years ago
I had this whole other comment cooked up, but then I went and read the other
comments in this bug little closer...  Being that we're moving to the point
where we do all the processing before we output anything at all, I'd say comment
7 is a good solution.  We can assume that if we have an error while processing
stuff, that no header has been put out (unless that error occured while
processing the template).  That would elminiate and need to keep track of if the
http header had been closed on not (which is basically what I was gonna
suggest).  And Gerv's suggestion in comment 7 also nicely accounts for the fact
that we can have more than one output format.
This can now be fixed by using ThrowTemplateError($error) in all || arms of
template->process() calls, instead of DisplayError() (which is now deprecated.)

When we do the global template fixup (see bug 135707) before 2.16, this
conversion will get done.

Severity: trivial → normal
Target Milestone: Bugzilla 2.18 → Bugzilla 2.16
setting dependencies per Gerv's comment #9
Blocks: 135707
Whiteboard: [blocker will fix]
This bug should now be fixed. 

Last Resolved: 16 years ago
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.