Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#13944 closed (fixed)

Very long accept-language headers break parser

Reported by: Russell Keith-Magee Owned by: nobody
Component: *.djangoproject.com Version: 1.2
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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

Attachments (1)

13944-tests.diff (960 bytes ) - added by Ramiro Morales 14 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 by Russell Keith-Magee, 14 years ago

Triage Stage: UnreviewedAccepted

comment:2 by Russell Keith-Magee, 14 years ago

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

by Ramiro Morales, 14 years ago

Attachment: 13944-tests.diff added

comment:3 by Ramiro Morales, 14 years ago

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.

in reply to:  3 comment:4 by anonymous, 14 years ago

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)

comment:5 by Gregor Müllegger, 14 years ago

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".

comment:6 by Russell Keith-Magee, 14 years ago

Component: InternationalizationDjango Web site

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.

comment:7 by Russell Keith-Magee, 14 years ago

Resolution: fixed
Status: newclosed

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.

comment:8 by Jacob, 13 years ago

milestone: 1.3

Milestone 1.3 deleted

Note: See TracTickets for help on using tickets.
Back to Top