Code

Opened 2 years ago

Last modified 2 years ago

#17719 new Bug

Improper parsing of template block and variable tags

Reported by: development@… Owned by: nobody
Component: Documentation Version: 1.3
Severity: Normal 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

Django template parsing (Lexer) looks for the first occurrence of %} after a {% when determining what a block tag is. This prevents the use of "%}" as a string literal. So a template syntax error will be raised for the following valid expressions:

  {% include "template.html" tvar="Some string literal with %} in it." %}
  {% with tvar="Some string literal with %} in it." %}{% endwith %}

This is also true for variable tag parsing. Example:

  {{ some.variable|default:"}}" }}

If this is expected/intended behavior, it doesn't appear to be documented anywhere.

The actual fix doesn't look trivial, but shouldn't be too bad. I could help with a fix if there's interest in that.

Attachments (0)

Change History (2)

comment:1 follow-up: Changed 2 years ago by lrekucki

  • Component changed from Template system to Documentation
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

I don't think it's possible to fix this without either an API change or adding some escape sequence (which could also be backwards incompatible). There is one place this is documented: https://docs.djangoproject.com/en/dev/ref/templates/builtins/#templatetag. It doesn't explicitly mention string literals, but OTOH there is no strict concept of string literals in the docs. Maybe add a section about them here, between Variables and Filters. This could also include this edge case.

comment:2 in reply to: ↑ 1 Changed 2 years ago by Glenn Washburn <development@…>

Replying to lrekucki:

I don't think it's possible to fix this without either an API change or adding some escape sequence (which could also be backwards incompatible). There is one place this is documented: https://docs.djangoproject.com/en/dev/ref/templates/builtins/#templatetag. It doesn't explicitly mention string literals, but OTOH there is no strict concept of string literals in the docs. Maybe add a section about them here, between Variables and Filters. This could also include this edge case.

The documentation for templatetag states: "to display one of the bits used in template tags". This is definitely misleading if its supposed to cover this issue because the string literal need not be displayed anywhere. It could for instance just be a string literal passed to a custom template tag for other purposes.

Thinking about it more, its worse than I thought. You're right, the fix would need to be pretty drastic. The crux of the issue is that Lexer (and Parser) doesn't know about string literals. But because tag contents can be anything, the Lexer wouldn't know how to parse them. I think the best solution is a documentation update for now.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new
The owner will be changed from nobody to anonymous. Next status will be 'assigned'
as The resolution will be set. Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.