You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@freemarker.apache.org by Woonsan Ko <wo...@apache.org> on 2015/10/08 23:52:58 UTC
Just created content-type and locale issues in JIRA
Hi folks,
I've just created two JIRA issues:
- https://issues.apache.org/jira/browse/FREEMARKER-1
- https://issues.apache.org/jira/browse/FREEMARKER-2
Yeah, number 1 and 2! :)
Those were actually discussed in the old ML. I contracted those to the
two issues.
Hopefully I can create PRs and ask for review sooner or later.
Thanks!
Cheers,
Woonsan
Re: Proposal: Extended FreemarkerServlet response Content-type and charset logic (Was: Re: Just created content-type and locale issues in JIRA)
Posted by Daniel Dekany <dd...@freemail.hu>.
I have committed the OverrideResponseContentType
always/never/whenTemplateHasMimeType thing. (Also did some further
cleanup.) So update before you modify anything.
--
Thanks,
Daniel Dekany
Wednesday, October 21, 2015, 3:19:06 AM, Woonsan Ko wrote:
> On Wed, Oct 21, 2015 at 5:12 AM, Daniel Dekany <dd...@freemail.hu> wrote:
>> Tuesday, October 20, 2015, 6:08:33 AM, Woonsan Ko wrote:
>>
>>> Hi Daniel,
>>>
>>> Thanks a lot for the reasonable/thorough analysis and solutions!
>>> Yes, your proposal will solve our problem (FREEMARKER-1). We can
>>> probably set it to "never" in our default configuration.
>>>
>>> In our case, our MVC framework allows developers to set response
>>> content type to anything before dispatching to freemarker servlet. For
>>> example, they can set "text/html", "application/xml",
>>> "application/json", "application/vnd.api+json", or whatever they want
>>> to use. In that case, some developers prefers setting a content type
>>> in a controller with setting model beans (which can be written as
>>> string, html, xml or json string) in request attributes before
>>> dispatching to freemarker servlet.
>>> I understand it can be solved in different ways, but I'd like to
>>> support them with what they're allowed to by servlet specification.
>>> Your proposal with the different options seems fulfilling this.
>>
>> OK, so that's how it will be, unless somebody else says something.
>>
>> We may also need a protected getDefaultOverrideRequestContentType()
>> method, so that a subclass can change the default from "always".
>
> That would be nice!
>
>>
>> Any comments about the output charset selection? How do you at Hippo
>> control that?
>
> Mostly they have been okay with the default ContentType configuration
> as init param: "text/html; charset=UTF-8". This default configuration
> has fulfilled most of our use cases even if they want to control it in
> controllers in some cases. Also probably they are okay with UTF-8
> encoding in almost every case.
> All those options ("fromTemplate", "always ${charset}" and "doNotSet")
> seem like good options to choose. Personally speaking, due to nature
> of our HMVC (with which the top ancestor controller's template's
> contentType setting will win), I normally recommend our customers to
> set it globally, not from template in most cases, just to avoid
> confusions from the controller component hierarchy.
>
>>
>>> By the way, regarding FREEMARKET-2, maybe do we need to have
>>> somethings similar for FreemarkerServlet#deduceLocale() with
>>> "OverrideResponseLocale" init-param? e.g, "always" and "never".
>>> "never" behaves like "always" if HttpServletRequest#getLocale()
>>> returns null.
>>
>> So, OverrideResponseLocale "never" wouldn't even call deduceLocale()
>> if servletRequest.locale is non-null. Otherwise we call deduceLocale()
>> and use what it returns. A bit twisted in that an overridden
>> deduceLocale() could do all this alone (examine servletRequest.locale,
>> decide if it will override it), but I guess this is the most practical
>> compromise.
>
> OK. Sounds great! Thanks for clarification! I'll try to create a PR
> for this soon.
>
>>
>> Note that for any of these init-params, even where right now we only
>> have two possible values, I prefer a string value over a boolean
>> because it's more future proof.
>
> Makes sense.
>
> Thanks a lot!
>
> Cheers,
>
> Woonsan
>
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>>> Regards,
>>>
>>> Woonsan
>>>
>>>
>>> On Mon, Oct 19, 2015 at 4:28 AM, Daniel Dekany <dd...@freemail.hu> wrote:
>>>> So I have merged this
>>>> (https://issues.apache.org/jira/browse/FREEMARKER-1) in, but while
>>>> reviewing the stuff, I have realized that I'm not sure how exactly
>>>> this should work, especially as OutputFormat-s (the main 2.3.24
>>>> feature, mostly used for auto-escaping, but usually also specifies a
>>>> MIME type) comes into the picture. As far as I see, the most generic
>>>> solution would be this:
>>>>
>>>> The new "OverrideResponseContentType" FreemarkerServlet init-param
>>>> (the topic of https://issues.apache.org/jira/browse/FREEMARKER-1)
>>>> could have three values:
>>>>
>>>> - "always": We always set it to something (see later to what),
>>>> overriding and ignoring anything that was in
>>>> servletResponse.contentType. This is the backward compatible mode,
>>>> and so the default. I also believe that this happens to be good
>>>> default regardless of backward compatibility, because it's the
>>>> business of the MVC View to decide such things as the MIME type.
>>>>
>>>> - "never": Never *overrides*, means if servletResponse.contentType
>>>> it null, it will still set it, like "always" does, otherwise it
>>>> just leaves servletResponse.contentType alone. This means that the
>>>> code that forwards to FreemarkerSerlvet has full control over the
>>>> servletResponse.contentType, if it cares to set it.
>>>>
>>>> - "whenTemplateHasContentType": If either the legacy "content_type"
>>>> custom template attribute is present (usually set with <#ftl
>>>> attributes={"content_type": "..."}>), or the template has an
>>>> associated OutputFormat that specifies a non-null MIME type (usually
>>>> "text/html"), then we behave as "always", otherwise as "never". The
>>>> logic behind this is that if a template has an associated MIME Type,
>>>> then that's certainly correct and shouldn't trampled on.
>>>> Applications may will mix legacy templates with those with
>>>> associated OutputFormat, that's why the "never" branch has
>>>> importance.
>>>>
>>>> So what does "always" set the content type to? We have a "ContentType"
>>>> FreemarkerServlet init-param since forever (defaulting to
>>>> "text/html"), and most often that's what we set it to. There's also an
>>>> old and obscure feature where you can specify a different one per
>>>> template via the "content_type" custom template attribute. But the
>>>> important new thing is that associating OutputFormat to each template
>>>> meant to become the norm in the future, and an OutputFormat usually
>>>> specifies a MIME type too. So we have a non-obscure mechanism to
>>>> figure out the content type for an *individual* template, starting
>>>> from 2.3.24. (Of course most applications won't set up OutputFormat
>>>> associations for a long time, and in that case templates are
>>>> associated to the "undefined" OutputFormat, that specifies no MIME
>>>> type, so we just get the old behavior.)
>>>>
>>>> I have also realized that the way one can specify the output charset
>>>> with FreemarkerServlet is crude too. So I'm thinking about adding an
>>>> "ResponseCharacterEncoding" FreemarkerServlet init-param too. There
>>>> the most generic set of values would look like this:
>>>>
>>>> - "legacy": Default for backward compatibility. Has some strange
>>>> quirks... It doesn't mater how it works now, as it's a legacy.
>>>>
>>>> - "fromTemplate": We get the charset from template.getOutputEncoding(),
>>>> which is an optional setting existing for a good while. If that's
>>>> null, we use template.getEncoding(), which is the encoding of the
>>>> source file.
>>>>
>>>> - "always ${charset}", like "always UTF-8": We just always set it to that,
>>>> via ServletResponse.setCharacterEncoding.
>>>>
>>>> - "doNotSet": We just don't set it, ever. (We can't detect if it was
>>>> set in the ServletRequest by the forwared, so we can't be smarter, I
>>>> believe.)
>>>>
>>>> A side note is that the modes other than "legacy" will need at least
>>>> Servlet 2.4, so that we will have
>>>> ServletResponse.setCharacterEncoding, instead of wresting with
>>>> appending it the charset to the contentType.
>>>>
>>>> Comments, ideas? How does this fit your applications?
>>>>
>>>> --
>>>> Thanks,
>>>> Daniel Dekany
>>>>
>>>>
>>>>
>>>> Sunday, October 11, 2015, 4:43:13 AM, Woonsan Ko wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I've just created a PR for FREEMARKER-1:
>>>>> - https://github.com/apache/incubator-freemarker/pull/1
>>>>>
>>>>> I suppose that PR should be automatically posted here soon.
>>>>>
>>>>> Just for information, PRs on the github mirror can be applied in the
>>>>> way as explained in the "Applying Pull Requests (for git based
>>>>> components)" section [1].
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Woonsan
>>>>>
>>>>> [1] https://wiki.apache.org/commons/UsingGIT
>>>>>
>>>>>
>>>>> On Fri, Oct 9, 2015 at 6:52 AM, Woonsan Ko <wo...@apache.org> wrote:
>>>>>> Hi folks,
>>>>>>
>>>>>> I've just created two JIRA issues:
>>>>>> - https://issues.apache.org/jira/browse/FREEMARKER-1
>>>>>> - https://issues.apache.org/jira/browse/FREEMARKER-2
>>>>>>
>>>>>> Yeah, number 1 and 2! :)
>>>>>>
>>>>>> Those were actually discussed in the old ML. I contracted those to the
>>>>>> two issues.
>>>>>> Hopefully I can create PRs and ask for review sooner or later.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Woonsan
>>>>>
>>>>
>>>
>>
>
--
Thanks,
Daniel Dekany
Re: Proposal: Extended FreemarkerServlet response Content-type and
charset logic (Was: Re: Just created content-type and locale issues in JIRA)
Posted by Woonsan Ko <wo...@apache.org>.
On Wed, Oct 21, 2015 at 5:12 AM, Daniel Dekany <dd...@freemail.hu> wrote:
> Tuesday, October 20, 2015, 6:08:33 AM, Woonsan Ko wrote:
>
>> Hi Daniel,
>>
>> Thanks a lot for the reasonable/thorough analysis and solutions!
>> Yes, your proposal will solve our problem (FREEMARKER-1). We can
>> probably set it to "never" in our default configuration.
>>
>> In our case, our MVC framework allows developers to set response
>> content type to anything before dispatching to freemarker servlet. For
>> example, they can set "text/html", "application/xml",
>> "application/json", "application/vnd.api+json", or whatever they want
>> to use. In that case, some developers prefers setting a content type
>> in a controller with setting model beans (which can be written as
>> string, html, xml or json string) in request attributes before
>> dispatching to freemarker servlet.
>> I understand it can be solved in different ways, but I'd like to
>> support them with what they're allowed to by servlet specification.
>> Your proposal with the different options seems fulfilling this.
>
> OK, so that's how it will be, unless somebody else says something.
>
> We may also need a protected getDefaultOverrideRequestContentType()
> method, so that a subclass can change the default from "always".
That would be nice!
>
> Any comments about the output charset selection? How do you at Hippo
> control that?
Mostly they have been okay with the default ContentType configuration
as init param: "text/html; charset=UTF-8". This default configuration
has fulfilled most of our use cases even if they want to control it in
controllers in some cases. Also probably they are okay with UTF-8
encoding in almost every case.
All those options ("fromTemplate", "always ${charset}" and "doNotSet")
seem like good options to choose. Personally speaking, due to nature
of our HMVC (with which the top ancestor controller's template's
contentType setting will win), I normally recommend our customers to
set it globally, not from template in most cases, just to avoid
confusions from the controller component hierarchy.
>
>> By the way, regarding FREEMARKET-2, maybe do we need to have
>> somethings similar for FreemarkerServlet#deduceLocale() with
>> "OverrideResponseLocale" init-param? e.g, "always" and "never".
>> "never" behaves like "always" if HttpServletRequest#getLocale()
>> returns null.
>
> So, OverrideResponseLocale "never" wouldn't even call deduceLocale()
> if servletRequest.locale is non-null. Otherwise we call deduceLocale()
> and use what it returns. A bit twisted in that an overridden
> deduceLocale() could do all this alone (examine servletRequest.locale,
> decide if it will override it), but I guess this is the most practical
> compromise.
OK. Sounds great! Thanks for clarification! I'll try to create a PR
for this soon.
>
> Note that for any of these init-params, even where right now we only
> have two possible values, I prefer a string value over a boolean
> because it's more future proof.
Makes sense.
Thanks a lot!
Cheers,
Woonsan
>
> --
> Thanks,
> Daniel Dekany
>
>> Regards,
>>
>> Woonsan
>>
>>
>> On Mon, Oct 19, 2015 at 4:28 AM, Daniel Dekany <dd...@freemail.hu> wrote:
>>> So I have merged this
>>> (https://issues.apache.org/jira/browse/FREEMARKER-1) in, but while
>>> reviewing the stuff, I have realized that I'm not sure how exactly
>>> this should work, especially as OutputFormat-s (the main 2.3.24
>>> feature, mostly used for auto-escaping, but usually also specifies a
>>> MIME type) comes into the picture. As far as I see, the most generic
>>> solution would be this:
>>>
>>> The new "OverrideResponseContentType" FreemarkerServlet init-param
>>> (the topic of https://issues.apache.org/jira/browse/FREEMARKER-1)
>>> could have three values:
>>>
>>> - "always": We always set it to something (see later to what),
>>> overriding and ignoring anything that was in
>>> servletResponse.contentType. This is the backward compatible mode,
>>> and so the default. I also believe that this happens to be good
>>> default regardless of backward compatibility, because it's the
>>> business of the MVC View to decide such things as the MIME type.
>>>
>>> - "never": Never *overrides*, means if servletResponse.contentType
>>> it null, it will still set it, like "always" does, otherwise it
>>> just leaves servletResponse.contentType alone. This means that the
>>> code that forwards to FreemarkerSerlvet has full control over the
>>> servletResponse.contentType, if it cares to set it.
>>>
>>> - "whenTemplateHasContentType": If either the legacy "content_type"
>>> custom template attribute is present (usually set with <#ftl
>>> attributes={"content_type": "..."}>), or the template has an
>>> associated OutputFormat that specifies a non-null MIME type (usually
>>> "text/html"), then we behave as "always", otherwise as "never". The
>>> logic behind this is that if a template has an associated MIME Type,
>>> then that's certainly correct and shouldn't trampled on.
>>> Applications may will mix legacy templates with those with
>>> associated OutputFormat, that's why the "never" branch has
>>> importance.
>>>
>>> So what does "always" set the content type to? We have a "ContentType"
>>> FreemarkerServlet init-param since forever (defaulting to
>>> "text/html"), and most often that's what we set it to. There's also an
>>> old and obscure feature where you can specify a different one per
>>> template via the "content_type" custom template attribute. But the
>>> important new thing is that associating OutputFormat to each template
>>> meant to become the norm in the future, and an OutputFormat usually
>>> specifies a MIME type too. So we have a non-obscure mechanism to
>>> figure out the content type for an *individual* template, starting
>>> from 2.3.24. (Of course most applications won't set up OutputFormat
>>> associations for a long time, and in that case templates are
>>> associated to the "undefined" OutputFormat, that specifies no MIME
>>> type, so we just get the old behavior.)
>>>
>>> I have also realized that the way one can specify the output charset
>>> with FreemarkerServlet is crude too. So I'm thinking about adding an
>>> "ResponseCharacterEncoding" FreemarkerServlet init-param too. There
>>> the most generic set of values would look like this:
>>>
>>> - "legacy": Default for backward compatibility. Has some strange
>>> quirks... It doesn't mater how it works now, as it's a legacy.
>>>
>>> - "fromTemplate": We get the charset from template.getOutputEncoding(),
>>> which is an optional setting existing for a good while. If that's
>>> null, we use template.getEncoding(), which is the encoding of the
>>> source file.
>>>
>>> - "always ${charset}", like "always UTF-8": We just always set it to that,
>>> via ServletResponse.setCharacterEncoding.
>>>
>>> - "doNotSet": We just don't set it, ever. (We can't detect if it was
>>> set in the ServletRequest by the forwared, so we can't be smarter, I
>>> believe.)
>>>
>>> A side note is that the modes other than "legacy" will need at least
>>> Servlet 2.4, so that we will have
>>> ServletResponse.setCharacterEncoding, instead of wresting with
>>> appending it the charset to the contentType.
>>>
>>> Comments, ideas? How does this fit your applications?
>>>
>>> --
>>> Thanks,
>>> Daniel Dekany
>>>
>>>
>>>
>>> Sunday, October 11, 2015, 4:43:13 AM, Woonsan Ko wrote:
>>>
>>>> Hi,
>>>>
>>>> I've just created a PR for FREEMARKER-1:
>>>> - https://github.com/apache/incubator-freemarker/pull/1
>>>>
>>>> I suppose that PR should be automatically posted here soon.
>>>>
>>>> Just for information, PRs on the github mirror can be applied in the
>>>> way as explained in the "Applying Pull Requests (for git based
>>>> components)" section [1].
>>>>
>>>> Cheers,
>>>>
>>>> Woonsan
>>>>
>>>> [1] https://wiki.apache.org/commons/UsingGIT
>>>>
>>>>
>>>> On Fri, Oct 9, 2015 at 6:52 AM, Woonsan Ko <wo...@apache.org> wrote:
>>>>> Hi folks,
>>>>>
>>>>> I've just created two JIRA issues:
>>>>> - https://issues.apache.org/jira/browse/FREEMARKER-1
>>>>> - https://issues.apache.org/jira/browse/FREEMARKER-2
>>>>>
>>>>> Yeah, number 1 and 2! :)
>>>>>
>>>>> Those were actually discussed in the old ML. I contracted those to the
>>>>> two issues.
>>>>> Hopefully I can create PRs and ask for review sooner or later.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Woonsan
>>>>
>>>
>>
>
Re: Proposal: Extended FreemarkerServlet response Content-type and charset logic (Was: Re: Just created content-type and locale issues in JIRA)
Posted by Daniel Dekany <dd...@freemail.hu>.
Tuesday, October 20, 2015, 6:08:33 AM, Woonsan Ko wrote:
> Hi Daniel,
>
> Thanks a lot for the reasonable/thorough analysis and solutions!
> Yes, your proposal will solve our problem (FREEMARKER-1). We can
> probably set it to "never" in our default configuration.
>
> In our case, our MVC framework allows developers to set response
> content type to anything before dispatching to freemarker servlet. For
> example, they can set "text/html", "application/xml",
> "application/json", "application/vnd.api+json", or whatever they want
> to use. In that case, some developers prefers setting a content type
> in a controller with setting model beans (which can be written as
> string, html, xml or json string) in request attributes before
> dispatching to freemarker servlet.
> I understand it can be solved in different ways, but I'd like to
> support them with what they're allowed to by servlet specification.
> Your proposal with the different options seems fulfilling this.
OK, so that's how it will be, unless somebody else says something.
We may also need a protected getDefaultOverrideRequestContentType()
method, so that a subclass can change the default from "always".
Any comments about the output charset selection? How do you at Hippo
control that?
> By the way, regarding FREEMARKET-2, maybe do we need to have
> somethings similar for FreemarkerServlet#deduceLocale() with
> "OverrideResponseLocale" init-param? e.g, "always" and "never".
> "never" behaves like "always" if HttpServletRequest#getLocale()
> returns null.
So, OverrideResponseLocale "never" wouldn't even call deduceLocale()
if servletRequest.locale is non-null. Otherwise we call deduceLocale()
and use what it returns. A bit twisted in that an overridden
deduceLocale() could do all this alone (examine servletRequest.locale,
decide if it will override it), but I guess this is the most practical
compromise.
Note that for any of these init-params, even where right now we only
have two possible values, I prefer a string value over a boolean
because it's more future proof.
--
Thanks,
Daniel Dekany
> Regards,
>
> Woonsan
>
>
> On Mon, Oct 19, 2015 at 4:28 AM, Daniel Dekany <dd...@freemail.hu> wrote:
>> So I have merged this
>> (https://issues.apache.org/jira/browse/FREEMARKER-1) in, but while
>> reviewing the stuff, I have realized that I'm not sure how exactly
>> this should work, especially as OutputFormat-s (the main 2.3.24
>> feature, mostly used for auto-escaping, but usually also specifies a
>> MIME type) comes into the picture. As far as I see, the most generic
>> solution would be this:
>>
>> The new "OverrideResponseContentType" FreemarkerServlet init-param
>> (the topic of https://issues.apache.org/jira/browse/FREEMARKER-1)
>> could have three values:
>>
>> - "always": We always set it to something (see later to what),
>> overriding and ignoring anything that was in
>> servletResponse.contentType. This is the backward compatible mode,
>> and so the default. I also believe that this happens to be good
>> default regardless of backward compatibility, because it's the
>> business of the MVC View to decide such things as the MIME type.
>>
>> - "never": Never *overrides*, means if servletResponse.contentType
>> it null, it will still set it, like "always" does, otherwise it
>> just leaves servletResponse.contentType alone. This means that the
>> code that forwards to FreemarkerSerlvet has full control over the
>> servletResponse.contentType, if it cares to set it.
>>
>> - "whenTemplateHasContentType": If either the legacy "content_type"
>> custom template attribute is present (usually set with <#ftl
>> attributes={"content_type": "..."}>), or the template has an
>> associated OutputFormat that specifies a non-null MIME type (usually
>> "text/html"), then we behave as "always", otherwise as "never". The
>> logic behind this is that if a template has an associated MIME Type,
>> then that's certainly correct and shouldn't trampled on.
>> Applications may will mix legacy templates with those with
>> associated OutputFormat, that's why the "never" branch has
>> importance.
>>
>> So what does "always" set the content type to? We have a "ContentType"
>> FreemarkerServlet init-param since forever (defaulting to
>> "text/html"), and most often that's what we set it to. There's also an
>> old and obscure feature where you can specify a different one per
>> template via the "content_type" custom template attribute. But the
>> important new thing is that associating OutputFormat to each template
>> meant to become the norm in the future, and an OutputFormat usually
>> specifies a MIME type too. So we have a non-obscure mechanism to
>> figure out the content type for an *individual* template, starting
>> from 2.3.24. (Of course most applications won't set up OutputFormat
>> associations for a long time, and in that case templates are
>> associated to the "undefined" OutputFormat, that specifies no MIME
>> type, so we just get the old behavior.)
>>
>> I have also realized that the way one can specify the output charset
>> with FreemarkerServlet is crude too. So I'm thinking about adding an
>> "ResponseCharacterEncoding" FreemarkerServlet init-param too. There
>> the most generic set of values would look like this:
>>
>> - "legacy": Default for backward compatibility. Has some strange
>> quirks... It doesn't mater how it works now, as it's a legacy.
>>
>> - "fromTemplate": We get the charset from template.getOutputEncoding(),
>> which is an optional setting existing for a good while. If that's
>> null, we use template.getEncoding(), which is the encoding of the
>> source file.
>>
>> - "always ${charset}", like "always UTF-8": We just always set it to that,
>> via ServletResponse.setCharacterEncoding.
>>
>> - "doNotSet": We just don't set it, ever. (We can't detect if it was
>> set in the ServletRequest by the forwared, so we can't be smarter, I
>> believe.)
>>
>> A side note is that the modes other than "legacy" will need at least
>> Servlet 2.4, so that we will have
>> ServletResponse.setCharacterEncoding, instead of wresting with
>> appending it the charset to the contentType.
>>
>> Comments, ideas? How does this fit your applications?
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>>
>>
>> Sunday, October 11, 2015, 4:43:13 AM, Woonsan Ko wrote:
>>
>>> Hi,
>>>
>>> I've just created a PR for FREEMARKER-1:
>>> - https://github.com/apache/incubator-freemarker/pull/1
>>>
>>> I suppose that PR should be automatically posted here soon.
>>>
>>> Just for information, PRs on the github mirror can be applied in the
>>> way as explained in the "Applying Pull Requests (for git based
>>> components)" section [1].
>>>
>>> Cheers,
>>>
>>> Woonsan
>>>
>>> [1] https://wiki.apache.org/commons/UsingGIT
>>>
>>>
>>> On Fri, Oct 9, 2015 at 6:52 AM, Woonsan Ko <wo...@apache.org> wrote:
>>>> Hi folks,
>>>>
>>>> I've just created two JIRA issues:
>>>> - https://issues.apache.org/jira/browse/FREEMARKER-1
>>>> - https://issues.apache.org/jira/browse/FREEMARKER-2
>>>>
>>>> Yeah, number 1 and 2! :)
>>>>
>>>> Those were actually discussed in the old ML. I contracted those to the
>>>> two issues.
>>>> Hopefully I can create PRs and ask for review sooner or later.
>>>>
>>>> Thanks!
>>>>
>>>> Cheers,
>>>>
>>>> Woonsan
>>>
>>
>
Re: Proposal: Extended FreemarkerServlet response Content-type and
charset logic (Was: Re: Just created content-type and locale issues in JIRA)
Posted by Woonsan Ko <wo...@apache.org>.
Hi Daniel,
Thanks a lot for the reasonable/thorough analysis and solutions!
Yes, your proposal will solve our problem (FREEMARKER-1). We can
probably set it to "never" in our default configuration.
In our case, our MVC framework allows developers to set response
content type to anything before dispatching to freemarker servlet. For
example, they can set "text/html", "application/xml",
"application/json", "application/vnd.api+json", or whatever they want
to use. In that case, some developers prefers setting a content type
in a controller with setting model beans (which can be written as
string, html, xml or json string) in request attributes before
dispatching to freemarker servlet.
I understand it can be solved in different ways, but I'd like to
support them with what they're allowed to by servlet specification.
Your proposal with the different options seems fulfilling this.
By the way, regarding FREEMARKET-2, maybe do we need to have
somethings similar for FreemarkerServlet#deduceLocale() with
"OverrideResponseLocale" init-param? e.g, "always" and "never".
"never" behaves like "always" if HttpServletRequest#getLocale()
returns null.
Regards,
Woonsan
On Mon, Oct 19, 2015 at 4:28 AM, Daniel Dekany <dd...@freemail.hu> wrote:
> So I have merged this
> (https://issues.apache.org/jira/browse/FREEMARKER-1) in, but while
> reviewing the stuff, I have realized that I'm not sure how exactly
> this should work, especially as OutputFormat-s (the main 2.3.24
> feature, mostly used for auto-escaping, but usually also specifies a
> MIME type) comes into the picture. As far as I see, the most generic
> solution would be this:
>
> The new "OverrideResponseContentType" FreemarkerServlet init-param
> (the topic of https://issues.apache.org/jira/browse/FREEMARKER-1)
> could have three values:
>
> - "always": We always set it to something (see later to what),
> overriding and ignoring anything that was in
> servletResponse.contentType. This is the backward compatible mode,
> and so the default. I also believe that this happens to be good
> default regardless of backward compatibility, because it's the
> business of the MVC View to decide such things as the MIME type.
>
> - "never": Never *overrides*, means if servletResponse.contentType
> it null, it will still set it, like "always" does, otherwise it
> just leaves servletResponse.contentType alone. This means that the
> code that forwards to FreemarkerSerlvet has full control over the
> servletResponse.contentType, if it cares to set it.
>
> - "whenTemplateHasContentType": If either the legacy "content_type"
> custom template attribute is present (usually set with <#ftl
> attributes={"content_type": "..."}>), or the template has an
> associated OutputFormat that specifies a non-null MIME type (usually
> "text/html"), then we behave as "always", otherwise as "never". The
> logic behind this is that if a template has an associated MIME Type,
> then that's certainly correct and shouldn't trampled on.
> Applications may will mix legacy templates with those with
> associated OutputFormat, that's why the "never" branch has
> importance.
>
> So what does "always" set the content type to? We have a "ContentType"
> FreemarkerServlet init-param since forever (defaulting to
> "text/html"), and most often that's what we set it to. There's also an
> old and obscure feature where you can specify a different one per
> template via the "content_type" custom template attribute. But the
> important new thing is that associating OutputFormat to each template
> meant to become the norm in the future, and an OutputFormat usually
> specifies a MIME type too. So we have a non-obscure mechanism to
> figure out the content type for an *individual* template, starting
> from 2.3.24. (Of course most applications won't set up OutputFormat
> associations for a long time, and in that case templates are
> associated to the "undefined" OutputFormat, that specifies no MIME
> type, so we just get the old behavior.)
>
> I have also realized that the way one can specify the output charset
> with FreemarkerServlet is crude too. So I'm thinking about adding an
> "ResponseCharacterEncoding" FreemarkerServlet init-param too. There
> the most generic set of values would look like this:
>
> - "legacy": Default for backward compatibility. Has some strange
> quirks... It doesn't mater how it works now, as it's a legacy.
>
> - "fromTemplate": We get the charset from template.getOutputEncoding(),
> which is an optional setting existing for a good while. If that's
> null, we use template.getEncoding(), which is the encoding of the
> source file.
>
> - "always ${charset}", like "always UTF-8": We just always set it to that,
> via ServletResponse.setCharacterEncoding.
>
> - "doNotSet": We just don't set it, ever. (We can't detect if it was
> set in the ServletRequest by the forwared, so we can't be smarter, I
> believe.)
>
> A side note is that the modes other than "legacy" will need at least
> Servlet 2.4, so that we will have
> ServletResponse.setCharacterEncoding, instead of wresting with
> appending it the charset to the contentType.
>
> Comments, ideas? How does this fit your applications?
>
> --
> Thanks,
> Daniel Dekany
>
>
>
> Sunday, October 11, 2015, 4:43:13 AM, Woonsan Ko wrote:
>
>> Hi,
>>
>> I've just created a PR for FREEMARKER-1:
>> - https://github.com/apache/incubator-freemarker/pull/1
>>
>> I suppose that PR should be automatically posted here soon.
>>
>> Just for information, PRs on the github mirror can be applied in the
>> way as explained in the "Applying Pull Requests (for git based
>> components)" section [1].
>>
>> Cheers,
>>
>> Woonsan
>>
>> [1] https://wiki.apache.org/commons/UsingGIT
>>
>>
>> On Fri, Oct 9, 2015 at 6:52 AM, Woonsan Ko <wo...@apache.org> wrote:
>>> Hi folks,
>>>
>>> I've just created two JIRA issues:
>>> - https://issues.apache.org/jira/browse/FREEMARKER-1
>>> - https://issues.apache.org/jira/browse/FREEMARKER-2
>>>
>>> Yeah, number 1 and 2! :)
>>>
>>> Those were actually discussed in the old ML. I contracted those to the
>>> two issues.
>>> Hopefully I can create PRs and ask for review sooner or later.
>>>
>>> Thanks!
>>>
>>> Cheers,
>>>
>>> Woonsan
>>
>
Proposal: Extended FreemarkerServlet response Content-type and charset logic (Was: Re: Just created content-type and locale issues in JIRA)
Posted by Daniel Dekany <dd...@freemail.hu>.
So I have merged this
(https://issues.apache.org/jira/browse/FREEMARKER-1) in, but while
reviewing the stuff, I have realized that I'm not sure how exactly
this should work, especially as OutputFormat-s (the main 2.3.24
feature, mostly used for auto-escaping, but usually also specifies a
MIME type) comes into the picture. As far as I see, the most generic
solution would be this:
The new "OverrideResponseContentType" FreemarkerServlet init-param
(the topic of https://issues.apache.org/jira/browse/FREEMARKER-1)
could have three values:
- "always": We always set it to something (see later to what),
overriding and ignoring anything that was in
servletResponse.contentType. This is the backward compatible mode,
and so the default. I also believe that this happens to be good
default regardless of backward compatibility, because it's the
business of the MVC View to decide such things as the MIME type.
- "never": Never *overrides*, means if servletResponse.contentType
it null, it will still set it, like "always" does, otherwise it
just leaves servletResponse.contentType alone. This means that the
code that forwards to FreemarkerSerlvet has full control over the
servletResponse.contentType, if it cares to set it.
- "whenTemplateHasContentType": If either the legacy "content_type"
custom template attribute is present (usually set with <#ftl
attributes={"content_type": "..."}>), or the template has an
associated OutputFormat that specifies a non-null MIME type (usually
"text/html"), then we behave as "always", otherwise as "never". The
logic behind this is that if a template has an associated MIME Type,
then that's certainly correct and shouldn't trampled on.
Applications may will mix legacy templates with those with
associated OutputFormat, that's why the "never" branch has
importance.
So what does "always" set the content type to? We have a "ContentType"
FreemarkerServlet init-param since forever (defaulting to
"text/html"), and most often that's what we set it to. There's also an
old and obscure feature where you can specify a different one per
template via the "content_type" custom template attribute. But the
important new thing is that associating OutputFormat to each template
meant to become the norm in the future, and an OutputFormat usually
specifies a MIME type too. So we have a non-obscure mechanism to
figure out the content type for an *individual* template, starting
from 2.3.24. (Of course most applications won't set up OutputFormat
associations for a long time, and in that case templates are
associated to the "undefined" OutputFormat, that specifies no MIME
type, so we just get the old behavior.)
I have also realized that the way one can specify the output charset
with FreemarkerServlet is crude too. So I'm thinking about adding an
"ResponseCharacterEncoding" FreemarkerServlet init-param too. There
the most generic set of values would look like this:
- "legacy": Default for backward compatibility. Has some strange
quirks... It doesn't mater how it works now, as it's a legacy.
- "fromTemplate": We get the charset from template.getOutputEncoding(),
which is an optional setting existing for a good while. If that's
null, we use template.getEncoding(), which is the encoding of the
source file.
- "always ${charset}", like "always UTF-8": We just always set it to that,
via ServletResponse.setCharacterEncoding.
- "doNotSet": We just don't set it, ever. (We can't detect if it was
set in the ServletRequest by the forwared, so we can't be smarter, I
believe.)
A side note is that the modes other than "legacy" will need at least
Servlet 2.4, so that we will have
ServletResponse.setCharacterEncoding, instead of wresting with
appending it the charset to the contentType.
Comments, ideas? How does this fit your applications?
--
Thanks,
Daniel Dekany
Sunday, October 11, 2015, 4:43:13 AM, Woonsan Ko wrote:
> Hi,
>
> I've just created a PR for FREEMARKER-1:
> - https://github.com/apache/incubator-freemarker/pull/1
>
> I suppose that PR should be automatically posted here soon.
>
> Just for information, PRs on the github mirror can be applied in the
> way as explained in the "Applying Pull Requests (for git based
> components)" section [1].
>
> Cheers,
>
> Woonsan
>
> [1] https://wiki.apache.org/commons/UsingGIT
>
>
> On Fri, Oct 9, 2015 at 6:52 AM, Woonsan Ko <wo...@apache.org> wrote:
>> Hi folks,
>>
>> I've just created two JIRA issues:
>> - https://issues.apache.org/jira/browse/FREEMARKER-1
>> - https://issues.apache.org/jira/browse/FREEMARKER-2
>>
>> Yeah, number 1 and 2! :)
>>
>> Those were actually discussed in the old ML. I contracted those to the
>> two issues.
>> Hopefully I can create PRs and ask for review sooner or later.
>>
>> Thanks!
>>
>> Cheers,
>>
>> Woonsan
>
Re: Just created content-type and locale issues in JIRA
Posted by Woonsan Ko <wo...@apache.org>.
Hi,
I've just created a PR for FREEMARKER-1:
- https://github.com/apache/incubator-freemarker/pull/1
I suppose that PR should be automatically posted here soon.
Just for information, PRs on the github mirror can be applied in the
way as explained in the "Applying Pull Requests (for git based
components)" section [1].
Cheers,
Woonsan
[1] https://wiki.apache.org/commons/UsingGIT
On Fri, Oct 9, 2015 at 6:52 AM, Woonsan Ko <wo...@apache.org> wrote:
> Hi folks,
>
> I've just created two JIRA issues:
> - https://issues.apache.org/jira/browse/FREEMARKER-1
> - https://issues.apache.org/jira/browse/FREEMARKER-2
>
> Yeah, number 1 and 2! :)
>
> Those were actually discussed in the old ML. I contracted those to the
> two issues.
> Hopefully I can create PRs and ask for review sooner or later.
>
> Thanks!
>
> Cheers,
>
> Woonsan