Am 01.04.2010, 08:29 Uhr, schrieb Charlie Clark <char...@begeistert.org>:
> I'm not sure if this is a CMF or Zope bug but some views, such as
> folder/view.html do not set the content-type properly which I think
> problems for some browsers. If this is a bug, how can I about fixing it?
After some more investigation I think this is a bug in
zope.pagetemplatefile: content sniffing only takes the <meta> tags for
content-type into account. Encoding will be set according to portal rules
but the comnbination can cause problems for some browsers (Firefox, at
least, ignores the charset and assumes latin-1). Furthermore, the
behaviour varies between the "classic" rendering and views. As views can
be configured without a dedicated class I can't see a CMF solution to this.
To test simply add some non-ascii to the "ursa" or "were" main_templates
and call the @@view.html in Firefox. For some reason CMFDefault's
@@view.html still renders correctly. I guess this must be related to the
__init__ in ursa globals. This probably needs patching so the behaviour is
the same. At least we've got tests for this.
I don't think depending on the meta declaration is the right approach.
I've seen it used incorrectly very often and it's supposed to be a hint
for the browser but will be overridden by the content-type in the header.
Better to add proper detection for the HTML Doctype in
zope.pagetemplate.pagetemplatefile. I'm not sure about the charset - I
think there's a way to check for the character encoding "manually" using
the BOM and this should be used with the meta declaration as a fall-back
and there should be an error if there is a mismatch. Should I submit a bug
Clark Consulting & Research
Zope-CMF maillist - Zope-CMF@zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests