[Zope-dev] zope-tests - FAILED: 3, OK: 30, UNKNOWN: 6
This is the summary for test reports received on the zope-tests list between 2012-02-23 00:00:00 UTC and 2012-02-24 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received [1]UNKNOWN : Zope-2.12 Python-2.6.6 : Linux [2]UNKNOWN : Zope-2.12-alltests Python-2.6.6 : Linux [3]UNKNOWN : Zope-2.13 Python-2.6.6 : Linux [4]UNKNOWN : Zope-2.13-alltests Python-2.6.6 : Linux [5]UNKNOWN : Zope-trunk Python-2.6.6 : Linux [6]UNKNOWN : Zope-trunk-alltests Python-2.6.6 : Linux ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.7 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit [7]Zope 3.4 KGS / Python2.4.6 64bit linux [8]Zope 3.4 KGS / Python2.5.5 64bit linux Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux [9]Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results -- [1]UNKNOWN UNKNOWN : Zope-2.12 Python-2.6.6 : Linux https://mail.zope.org/pipermail/zope-tests/2012-February/058545.html [2]UNKNOWN UNKNOWN : Zope-2.12-alltests Python-2.6.6 : Linux https://mail.zope.org/pipermail/zope-tests/2012-February/058546.html [3]UNKNOWN UNKNOWN : Zope-2.13 Python-2.6.6 : Linux https://mail.zope.org/pipermail/zope-tests/2012-February/058547.html [4]UNKNOWN UNKNOWN : Zope-2.13-alltests Python-2.6.6 : Linux https://mail.zope.org/pipermail/zope-tests/2012-February/058548.html [5]UNKNOWN UNKNOWN : Zope-trunk Python-2.6.6 : Linux https://mail.zope.org/pipermail/zope-tests/2012-February/058549.html [6]UNKNOWN UNKNOWN : Zope-trunk-alltests Python-2.6.6 : Linux https://mail.zope.org/pipermail/zope-tests/2012-February/058550.html [7]FAILED Zope 3.4 KGS / Python2.4.6 64bit linux https://mail.zope.org/pipermail/zope-tests/2012-February/058541.html [8]FAILED Zope 3.4 KGS / Python2.5.5 64bit linux https://mail.zope.org/pipermail/zope-tests/2012-February/058542.html [9]FAILED Zope 3.4 Known Good Set / py2.5-32bit-linux https://mail.zope.org/pipermail/zope-tests/2012-February/058540.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Content Type Meta tag stripping in zope.pagetemplate
On Fri, Feb 24, 2012 at 09:57:57PM +0100, Charlie Clark wrote: > Am 24.02.2012, 09:47 Uhr, schrieb Miano Njoka : > > >While it is not essential, it is necessary in some cases where the > >finished document will be read from disk or is used by other > >applications eg. Deliverance[http://packages.python.org/Deliverance/]. > >In fact w3c's HTML validator throws a warning that one should declare > >the character encoding in the document itself if it is missing. > > This is actually what the validator says: > > """ > No character encoding information was found within the document, > either in an HTML meta element or an XML declaration. It is often > recommended to declare the character encoding in the document > itself, especially if there is a chance that the document will be > read from or saved to disk, CD, etc. > """ > > As ZPT produces XHTML the proper place for any encoding declaration > is in the XML declaration, defaulting to UTF-8, which should throw a > validation error if incorrect. A strong -1 for zope.pagetemplate adding declarations automatically. > Like much of the HTML standard the > meta tags were never really thought through and, because invisible > to the user, all too often copied mindlessly from one project to > another: I have customers today with completely invalid and > misleading meta tags of which they and the rest of the world is > blissfully unware. And as a result browsers - the main consumers of > the format were made fault tolerant - after all the user often had > no idea what was causing the problem or how to rectify it. I have > seen many examples of the server saying one think and the meta > something else entirely. I think nearly all browsers believe what > the server says over what's in the meta tag. The HTML spec requires that: "To sum up, conforming user agents must observe the following priorities when determining a document's character encoding (from highest priority to lowest): 1. An HTTP "charset" parameter in a "Content-Type" field. 2. A META declaration with "http-equiv" set to "Content-Type" and a value set for "charset". 3. The charset attribute set on an element that designates an external resource." -- http://www.w3.org/TR/html4/charset.html#h-5.2.2 (Aside: The rationale for this ordering, IIRC, is that it allows HTTP servers to do on-the-fly charset conversion from one 8-bit charset to a different one, without having to parse HTML and modify the charset name in the declaration.) > According to MAMA, which was instrumental in developing HTML 5 based > on what has actually been written, the charset was set in the > http-headersover 99 % of the time. Unfortunately, it doesn't contain > any stats on discrepancies between the http-header and the meta. > > http://dev.opera.com/articles/view/mama > > While there is apparently a possible security risk when not > declaring the charset I think the Pythonic principle of "there > should be preferably one obvious way to do something" should apply > when within Zope trying to decide the charset of a file and that > should be well documented. I'd suggest keeping the stripping but > implementing a more rigorous approach such as you suggest. I'm not a big fan of the stripping. Consider people using wget to mirror websites (or some equivalent way -- hitting Save As in a browser and selecting "Web Page (original)" instead of "Web Page (complete)"). The Content-Type header is not going to be saved on disk. Why should zope.pagetemplate forbid programmers from duplicating the charset information in the element, at least as long as that information is correct (i.e. matches the content type)? Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Content Type Meta tag stripping in zope.pagetemplate
Am 24.02.2012, 09:47 Uhr, schrieb Miano Njoka : While it is not essential, it is necessary in some cases where the finished document will be read from disk or is used by other applications eg. Deliverance[http://packages.python.org/Deliverance/]. In fact w3c's HTML validator throws a warning that one should declare the character encoding in the document itself if it is missing. This is actually what the validator says: """ No character encoding information was found within the document, either in an HTML meta element or an XML declaration. It is often recommended to declare the character encoding in the document itself, especially if there is a chance that the document will be read from or saved to disk, CD, etc. """ As ZPT produces XHTML the proper place for any encoding declaration is in the XML declaration, defaulting to UTF-8, which should throw a validation error if incorrect. Like much of the HTML standard the meta tags were never really thought through and, because invisible to the user, all too often copied mindlessly from one project to another: I have customers today with completely invalid and misleading meta tags of which they and the rest of the world is blissfully unware. And as a result browsers - the main consumers of the format were made fault tolerant - after all the user often had no idea what was causing the problem or how to rectify it. I have seen many examples of the server saying one think and the meta something else entirely. I think nearly all browsers believe what the server says over what's in the meta tag. According to MAMA, which was instrumental in developing HTML 5 based on what has actually been written, the charset was set in the http-headersover 99 % of the time. Unfortunately, it doesn't contain any stats on discrepancies between the http-header and the meta. http://dev.opera.com/articles/view/mama While there is apparently a possible security risk when not declaring the charset I think the Pythonic principle of "there should be preferably one obvious way to do something" should apply when within Zope trying to decide the charset of a file and that should be well documented. I'd suggest keeping the stripping but implementing a more rigorous approach such as you suggest. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Content Type Meta tag stripping in zope.pagetemplate
On Thu, Feb 23, 2012 at 2:44 PM, Fred Drake wrote: > On Thu, Feb 23, 2012 at 2:54 AM, Miano Njoka wrote: >> Yes, this is true, but why strip out the meta tag from the resulting HTML? > > Two reasons: > > 1. It may be incorrect. > > 2. If multiple templates are used to construct a response, different > values may be included from each template, which may be inconsistent. > The code as it is now does not take this into account. It parses the meta content type tag from all the templates passed to it and the content type header sent in the response will be that of the last template processed. > Since the meta element is unnecessary, it seemed better to leave it out > of the result, While it is not essential, it is necessary in some cases where the finished document will be read from disk or is used by other applications eg. Deliverance[http://packages.python.org/Deliverance/]. In fact w3c's HTML validator throws a warning that one should declare the character encoding in the document itself if it is missing. > and rely on other components to render the correct values > without requiring them to insert correct values into the rendered template. Rather than removing the meta tag, I think its less complicated to leave it in the finished HTML and let the developer fix any inconsistencies that may arise. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
