This could very easily be a bug — the cached content most likely gets stored as chunks of HTML (or "markup") - and then when it's time to return those pre-cooked chunks, everyone has forgotten about the supposed ContentType Header change :-)
Come to think of it, I can't really see how it could even be fixed (or categorized as a bug per se)... It's really a hack because (IMO) you shouldn't really be able to do something like that in "the view" - but I understand why it's there.
If this should be fixed, the caching mechanism would suddenly need to do a lot more than just store the output, by having to look into each file and check for these types of hacks — which would only make it slower, I guess?
I actually think it's better to add a note on the wiki page for the extension, and mention the server control for those who need to use caching with this - don't you think?
ChangeContentType('text/xml') and Macro caching problem
Hi.
Iwe got the following xslt rendering: http://jmj.727.dk/xslt/xmlrest.xslt
Its works perfect, all browsers get the "text/xml" mimetype.
But if i enable caching (1800sec, Cache By Page) the mime types changes to text/html.
Iam using umbraco 4.9
Can anyone help me out ?
Best regards
Jacob
Hi Jacob,
This could very easily be a bug — the cached content most likely gets stored as chunks of HTML (or "markup") - and then when it's time to return those pre-cooked chunks, everyone has forgotten about the supposed ContentType Header change :-)
I suggest you check for a bug (and file it as such if not found) on http://issues.umbraco.org/issues
What you can try in the meantime, is to use the <umbraco:ContentType> server control in the template used for the macro, e.g.:
/Chriztian
Hi Chriztian
thx for ur reply, the template tags works perfectly (dident knew it excist, thx).
Ill check up on the bug section, if it not excist ill report it.
Again, thx for ur help !!
Best regards
Jacob
Hi Jacob,
You're welcome,
Come to think of it, I can't really see how it could even be fixed (or categorized as a bug per se)... It's really a hack because (IMO) you shouldn't really be able to do something like that in "the view" - but I understand why it's there.
If this should be fixed, the caching mechanism would suddenly need to do a lot more than just store the output, by having to look into each file and check for these types of hacks — which would only make it slower, I guess?
I actually think it's better to add a note on the wiki page for the extension, and mention the server control for those who need to use caching with this - don't you think?
/Chriztian
is working on a reply...