HTTP_ACCEPT_CHARSET parsing fragile

Bug #253362 reported by John Eikenberry
4
Affects Status Importance Assigned to Milestone
Zope 2
Fix Released
Low
Unassigned
Zope 3
Fix Released
Low
Unassigned

Bug Description

Received a malformed HTTP_ACCEPT_CHARSET which raised a ValueError instead
of trying its best. The header was from a bot, which I reported the issue
to. But seems like Zope could be a bit more resilient when dealing with a
broken HTTP_ACCEPT_CHARSET.

Here is the malformed header.

 'HTTP_ACCEPT_CHARSET': 'utf-8;q=0.7,iso-8859-1;q=0.2*;q=0.1',

The issue is a missing comma in that last bit, between the '0.2' and the
asterisk (*).

Below is the full traceback from Zope-2.10.5. I checked and the issue
remains in 2.11.1, though the lines numbers are a bit different.

Error Type: ValueError
Error Value: too many values to unpack

Traceback (innermost last):
    * Module ZPublisher.Publish, line 119, in publish
    * Module ZPublisher.mapply, line 88, in mapply
    * Module ZPublisher.Publish, line 42, in call_object
    * Module OFS.DTMLMethod, line 144, in __call__
      <DTMLMethod at /www_org/ContentRoot/index_html used for /www_org/ContentRoot/visitors/tell_a_friend>
      URL: http://www.mengonline.com/index_html/manage_main [^]
      Physical Path:/www_org/ContentRoot/index_html
    * Module DocumentTemplate.DT_String, line 476, in __call__
    * Module Products.DotOrg.Pages.KContent, line 237, in __call__
    * Module Products.DotOrg.KOFS.DTMLMethod, line 34, in __call__
    * Module Products.DotOrg.KOFS.DTMLUnicode, line 40, in __call__
    * Module OFS.DTMLMethod, line 144, in __call__
      <KContent at /www_org/ContentRoot/visitors/tell_a_friend/content>
      URL: http://www.mengonline.com/visitors/tell_a_friend/content/manage_main
      Physical Path:/www_org/ContentRoot/visitors/tell_a_friend/content
    * Module DocumentTemplate.DT_String, line 476, in __call__
    * Module Shared.DC.Scripts.Bindings, line 327, in __render_with_namespace__
    * Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec
    * Module App.special_dtml, line 178, in _exec
    * Module DocumentTemplate.DT_Let, line 76, in render
    * Module DocumentTemplate.ustr, line 44, in ustr
    * Module Products.DotOrg.Forms.KAppForm, line 87, in __str__
    * Module Products.DotOrg.Forms.KForm, line 326, in __str__
    * Module Products.DotOrg.Forms.KForm, line 274, in ordered_layout
    * Module Shared.DC.Scripts.Bindings, line 313, in __call__
    * Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec
    * Module Products.PageTemplates.PageTemplateFile, line 129, in _exec
    * Module Products.PageTemplates.PageTemplate, line 89, in pt_render
    * Module zope.pagetemplate.pagetemplate, line 117, in pt_render
    * Module zope.tal.talinterpreter, line 271, in __call__
    * Module zope.tal.talinterpreter, line 346, in interpret
    * Module zope.tal.talinterpreter, line 408, in do_startTag
    * Module zope.tal.talinterpreter, line 485, in attrAction_tal
    * Module Products.PageTemplates.Expressions, line 229, in evaluateText
    * Module Products.PageTemplates.Expressions, line 255, in _handleText
    * Module Products.PageTemplates.unicodeconflictresolver, line 69, in resolve
    * Module zope.publisher.http, line 1001, in getPreferredCharsets
ValueError: too many values to unpack

Revision history for this message
Andreas Jung (ajung) wrote :

The general question is how to treat malformed headers:
 - ignoring them and using some default
 - treating them like an error and answering with some HTTP error code
?

Andreas Jung (ajung)
Changed in zope2:
importance: Undecided → Low
Revision history for this message
Philipp von Weitershausen (philikon) wrote : Re: [Bug 253362] Re: HTTP_ACCEPT_CHARSET parsing fragile

I think we want to simply ignore malformed headers.

Revision history for this message
Andreas Jung (ajung) wrote :
Changed in zope2:
status: New → Fix Committed
Changed in zope3:
status: New → Fix Committed
Revision history for this message
Andreas Jung (ajung) wrote :

svn:externals for the Zope 2 trunk and 2.11 branch have been updated to
zope.publisher==3.4.3

Zope 2.10 point to zope.publisher==3.3.2 - however there is no zope.publisher 3.2 branch :->
So leaving this issue open for Zope 2.10.

Changed in zope3:
importance: Undecided → Low
Revision history for this message
Philipp von Weitershausen (philikon) wrote :

El 31 Jul 2008, a las 09:39 , Andreas Jung escribió:
> svn:externals for the Zope 2 trunk and 2.11 branch have been updated
> to
> zope.publisher==3.4.3
>
> Zope 2.10 point to zope.publisher==3.3.2 - however there is no
> zope.publisher 3.2 branch :->
> So leaving this issue open for Zope 2.10.

zope.publisher 3.3.x is before packages were split up into their own
eggs. Look for zope.publisher 3.3.x in the Zope3 3.3 branch.

Revision history for this message
Andreas Jung (ajung) wrote :

Also fixed on the Zope 3.3 branch:

http://svn.zope.org/Zope3/branches/3.3/?rev=89417&view=rev

However I won't cut a new Zope 3.3.3 release for this bug (so this bug remains unfixed for Zope 2.10 for now)

Revision history for this message
Wolfgang Schnerring (wosc) wrote :

released as zope.publisher-3.5.4

Changed in zope3:
status: Fix Committed → Fix Released
Changed in zope2:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.