Opened 6 years ago

Closed 6 years ago

Last modified 5 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: UI/UX:

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 6 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 6 years ago by Russell Keith-Magee

Triage Stage: UnreviewedAccepted

comment:2 Changed 6 years ago by Russell Keith-Magee

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

Changed 6 years ago by Ramiro Morales

Attachment: 13944-tests.diff added

comment:3 Changed 6 years ago by 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.

comment:4 in reply to:  3 Changed 6 years ago by 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)

comment:5 Changed 6 years ago by 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".

comment:6 Changed 6 years ago by Russell Keith-Magee

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 Changed 6 years ago by Russell Keith-Magee

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 Changed 5 years ago by Jacob

milestone: 1.3

Milestone 1.3 deleted

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