[WIP] Template with {contentType ...} rendered to string should not modify global application state

[jkuchar]

Anything rendered to string should not modify global application state. Unfortunately it is not a case with macro {contentType mime-type} which sets headers directly. ref to latte code

Expected behaviour would be to:

1. render() method modifies application output directly, it is expected to modify output headers
2. renderToString() should NOT modify headers - there should be some other API to get headers set by template

[fprochazka]

Sounds logical. Imho sending of the header should be removed altogether, as "sending a headers from templating engine" sounds very wrong when you say it out loud like this. Sadly, that would be a giant BC Break.

[jkuchar]

I think it is great that latte file knows it's content type. That's why latte is what it is - content escaping.

render() should behave the same as it behaves now. Method is dependent on script output anyway so I think it should send headers. Headers needs to be sent before output and it will be really tricky to implement without sending it directly from template because you know content type only at runtime. (e.g. {if $a}{contentType text}{/if} or {contentType $a})

(btw. this kind of type dynamic makes static analysis impossible) @JanTvrdik

renderToString(): It should just return string with output as it does now.

There can introduced something like renderToBuffer() which returns DTO with "response body" and headers.

[jkuchar]

Alternate solution can be to declare content type in static way. e.g. using template headers (something very similar to file-level docblock)

Then:

• render() then will not need to send headers anymore, because it will be easy to determine content-type before template execution
• renderToString() will remains the same
• there will be need for API to get root content type of given latte file

[fprochazka]

I think it is great that latte file knows it's content type. That's why latte is what it is - content escaping.

I agree, I just think the macro shouldn't be sending HTTP Headers.

---

In Lavito, we've implemented "the symfony way" of naming templates (while integrating latte into symfony)... that means .txt.latte is content type text, .html.latte is content type html. Imho it's cleaner, since you set the content type from outside, and you can read it easily from the prepared (and not yet rendered) object and send the header yourself if you must. We're using it for email templates, that are not yet in HTML, but plain. And we wouldn't want that to be sending any headers to the output - makes no sense.

it will be really tricky to implement without sending it directly from template because you know content type only at runtime

I disagree. We could make it that you have to set the type from control/presenter (some template object setter - compiler has that ability already) and deprecate the macro - which would solve the chicken egg problem of fetching the content type, sending the header and rendering the template. The real BC Break would be only those few templates where you have xml content-type macro for your exports/rss - and it can be easily fixed, since you can grep your project for the macro and find the template usage.

I agree the render() should not be changed for the compatibility's sake. But still I think in 3.* releases it might be a good idea to break that and it's good that you brought up this issue.

[jkuchar]

We could also make it that you have to set the type from control/presenter (some template object setter - compiler has that ability already)

I do not agree with this. I has two downsites:

• no way for static analysis to know what content type is inside (you are defining content-type again at runtime)
• you can interpret one latte template from to places with two different content types which can lead into XSS attack vulnerability)

---

Template for itself must know what is inside. I think there are two meaningfull ways of doing that:

• filename as proposed by Filip
  • plus: easy to implement + easy to understand
  • minus: file-system dependency (compiler should has content type as parameter and [Engine](https://api.nette.org/2.3.9/Latte.Engine.html] should determine content type from filename)
• by introducing latte header (e.g. must be first macro in file, etc.)
  • plus: latte itself knows what is inside; there will be not API change to Compiler:compile() and Engine
  • plus: contentType can act as "header macro" (first macro in latte; no variables) will be easy to introduce without BC
  • when using PresenterResponse there will be no BC, because it will send header retrieved from template
  • minus: requires to add new syntax into latte

[dg]

Just note: {contentType} sends HTTP header only when you pass full mimetype ie {contentType application/javascript}. For content sensitive escaping is enough to specify {contentType javascript} and no header is sent.