Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#33245 closed Bug (fixed)

utils.html.urlize() isn't thread-safe

Reported by: Tim McCurrach Owned by: Tim McCurrach
Component: Utilities Version: dev
Severity: Release blocker Keywords:
Cc: Claude Paroz Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Tim McCurrach)

Since e567670b utils.html.urlize isn't thread safe!

To replicate bug:

  1. Write 2 views that both use the urlizetrunc tag a large number of times (between 104 and 105 was enough on my computer).
  2. Use different url length limits (for truncation) for each view
  3. Load the 2 views simultaneously

The resulting pages will have inconsistent url limits, as the trim_url_limit value from one view leaks over to the other.

The cause

Since urlize was changed to become class-based trim_url_limit, nofollow, autoescape, and trim_url_limit are stored as instance attributes. Urlizer is instantiated just once and then used within urlize which allows for these values to be shared between function calls.

The solution

  • The obvious solution would be to pass the values listed above directly to handle_word so that they are not stored on the instance.
  • My only question is: Does removing these values from the class instance nullify the ease of customisation the original ticket brought about? If this is the case, the better solution might just be to revert the change.
  • An alternative approach would be to create a new instance of Urlizer on each call of urlize, but since this can be called many times in a single request, this would likely have a performance impact.

Change History (9)

comment:1 by Tim McCurrach, 3 years ago

Description: modified (diff)

comment:2 by Tim McCurrach, 3 years ago

Summary: utils.urlize isn't thread-safeutils.html.urlize isn't thread-safe

comment:3 by Mariusz Felisiak, 3 years ago

Cc: Claude Paroz added
Severity: NormalRelease blocker
Summary: utils.html.urlize isn't thread-safeutils.html.urlize() isn't thread-safe
Triage Stage: UnreviewedAccepted

Thanks for the report!

The obvious solution would be to pass the values listed above directly to handle_word so that they are not stored on the instance.

Agreed, it's should be enough to pass values to the underlying methods.

My only question is: Does removing these values from the class instance nullify the ease of customisation the original ticket brought about?

I don't think so. As far as I'm aware all important parameters will still be customizable.

comment:4 by Jacob Walls, 3 years ago

Has patch: set
Owner: changed from nobody to Tim McCurrach
Status: newassigned

comment:5 by Claude Paroz, 3 years ago

[HS] Mariusz, do you know why I'm not receiving any mail when you CC me? It's not a problem since I generally follow the timeline, but I still wonder.

in reply to:  5 comment:6 by Tim McCurrach, 3 years ago

Replying to Claude Paroz:

[HS] Mariusz, do you know why I'm not receiving any mail when you CC me? It's not a problem since I generally follow the timeline, but I still wonder.

FWIW, I'm not receiving notifications about this ticket either. Strange...

comment:7 by Mariusz Felisiak, 3 years ago

Triage Stage: AcceptedReady for checkin

comment:8 by Mariusz Felisiak <felisiak.mariusz@…>, 3 years ago

Resolution: fixed
Status: assignedclosed

In ad81b606:

Fixed #33245 -- Made django.utils.html.urlize() thread-safe.

Regression in e567670b1abe61af4acfaa6a6a7e92a7acfa8b00.

comment:9 by GitHub <noreply@…>, 3 years ago

In 1f9874d4:

Refs #33245 -- Minor edits to django.utils.html.urlize() changes.

Follow up to ad81b606a2b5276397460a654fc7ad901a54b91e.

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