Very long accept-language headers break parser

[Russell Keith-Magee]

The parse_accept_language_header() function in utils/translation/trans_real.py uses a regular expression to parse accept-language headers.

This works well with RFC2616 compliant data, but breaks if bad data is passed in -- in particular, a string that exceeds 16 characters in length. This can result in pages not returning from the server.

A particular culprit here appears to be Weave; for some reason, on some configurations, it seems to put path names into the accept-language header. A path will often exceed 16 characters, triggering the problem.

To reproduce: set your accept-language header to: en-nz,en,de,chrome://global/locale/intl.properties

[Russell Keith-Magee]

This ticket was raised because of complaints that djangoproject.com wasn't returning content.

[Ramiro Morales]

I cant' reproduce this with the runtime enviroment set up by the django tests. Perhaps the one currently present in the djangoproject.com servers is triggering the issue?.

Attaching mods to the i18n regression tests showing the parsing of the header works as intended.

[anonymous]

Replying to ramiro:

I cant' reproduce this with the runtime enviroment set up by the django tests. Perhaps the one currently present in the djangoproject.com servers is triggering the issue?.

Attaching mods to the i18n regression tests showing the parsing of the header works as intended.

I'm also having this problem specificaly with the site while using Firefox. Here are my headers:

Host[docs.djangoproject.com]
User-Agent[Mozilla/5.0 (X11; U; Linux x86_64; pt-BR; rv:1.9.2.11pre) Gecko/20100928 Ubuntu/10.04 (lucid) Firefox/3.6.11pre]
Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8]
Accept-Language[pt-br,chrome://global/locale/intl.properties;q=0.5]
Accept-Encoding[gzip,deflate]
Accept-Charset[ISO-8859-1,utf-8;q=0.7,*;q=0.7]
Keep-Alive[115]
Connection[keep-alive]

(never mind the square brackets, they're just formatting helpers from the Tamper Data addon)

[Gregor Müllegger]

I can confirm this issue with Firefox 3.5. My intl.accept_languages config was set to chrome://global/locale/intl.properties somehow.

To fix this in the browser, open a new tab and enter "about.config", right click the "intl.accept_languages" config and choose "revert to default".

[Russell Keith-Magee]

On closer examination, this looks like it might be something specific to the djangoproject.com server. Like Ramiro, I can't reproduce the problem using trunk. I also can't reproduce the problem using the source code for djangoproject.com under the development server. However, I *can* reproduce the problem on the live djangoproject.com server.

[Russell Keith-Magee]

I've just tested this problem with the soon-to-be-released new server for djangoproject.com, and that server isn't affected. Whatever the problem is, it appears to be server related, and we'll fix the problem when we move to the new server.

[Jacob]

Milestone 1.3 deleted