Can't use X-UA-Compatible meta header when using Fanstatic
30 views
Skip to first unread message
Thierry Florac
May 23, 2013, 5:22:33 AM5/23/13
to fans...@googlegroups.com
Hi,
I need to define the "X-UA-Compatible" meta header for an intranet application using Fanstatic (actually 0.16).
Specifications says that this header must be placed "before any other header" in the HEAD tag; but even if I place it first, Fanstatic always inserts it's resources before it while rendering the page, making it ineffective.
Is there any way to handle this ?
Thanks,
Thierry
Martijn Faassen
May 23, 2013, 5:45:23 AM5/23/13
to fans...@googlegroups.com
Hi there,
I ran into this recently to try to trigger Chrome Frame. In the end I
went with sending a response header instead instead of going for meta,
but before that I hacked up this strategy:
I used fanstatic.register_inclusion_renderer to register a bogus
extension (.xua, say) with a particular renderer and a very low order
(you can make it negative). The lower order makes this inclusion be
sorted high up.
The renderer doesn't actually do anything with its URL argument, but
instead just returns a snippet of HTML with the X-UA-Compatible meta
header in it.
You need to then register a resource for your app with that extension
.xua. It needs to have a file present that isn't actually used (as you
don't refer to using your snippet), but to please Fanstatic.
After this I got the meta header appear above everything else. It
still didn't trigger Chrome Frame properly but that was possibly due
to other issues. :)
We need to have a simpler way to support this kind of stuff in
Fanstatic though; perhaps a way to explicitly control that Fanstatic
should insert only under existing link tags or script tags. Proposals
and patches are welcome!
Regards,
Martijn
> --
> You received this message because you are subscribed to the Google Groups
> "fanstatic" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fanstatic+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
I ran into this recently to try to trigger Chrome Frame. In the end I
went with sending a response header instead instead of going for meta,
but before that I hacked up this strategy:
I used fanstatic.register_inclusion_renderer to register a bogus
extension (.xua, say) with a particular renderer and a very low order
(you can make it negative). The lower order makes this inclusion be
sorted high up.
The renderer doesn't actually do anything with its URL argument, but
instead just returns a snippet of HTML with the X-UA-Compatible meta
header in it.
You need to then register a resource for your app with that extension
.xua. It needs to have a file present that isn't actually used (as you
don't refer to using your snippet), but to please Fanstatic.
After this I got the meta header appear above everything else. It
still didn't trigger Chrome Frame properly but that was possibly due
to other issues. :)
We need to have a simpler way to support this kind of stuff in
Fanstatic though; perhaps a way to explicitly control that Fanstatic
should insert only under existing link tags or script tags. Proposals
and patches are welcome!
Regards,
Martijn
> You received this message because you are subscribed to the Google Groups
> "fanstatic" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fanstatic+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
Jan-Jaap Driessen
May 23, 2013, 6:48:35 AM5/23/13
to fans...@googlegroups.com, tfl...@gmail.com
On Thu, May 23, 2013 at 11:45 AM, Martijn Faassen
<faa...@startifact.com> wrote:
> Hi there,
>
> I ran into this recently to try to trigger Chrome Frame. In the end I
> went with sending a response header instead instead of going for meta,
> but before that I hacked up this strategy:
>
> I used fanstatic.register_inclusion_renderer to register a bogus
> extension (.xua, say) with a particular renderer and a very low order
> (you can make it negative). The lower order makes this inclusion be
> sorted high up.
>
> The renderer doesn't actually do anything with its URL argument, but
> instead just returns a snippet of HTML with the X-UA-Compatible meta
> header in it.
>
> You need to then register a resource for your app with that extension
> .xua. It needs to have a file present that isn't actually used (as you
> don't refer to using your snippet), but to please Fanstatic.
>
> After this I got the meta header appear above everything else. It
> still didn't trigger Chrome Frame properly but that was possibly due
> to other issues. :)
>
> We need to have a simpler way to support this kind of stuff in
> Fanstatic though; perhaps a way to explicitly control that Fanstatic
> should insert only under existing link tags or script tags. Proposals
> and patches are welcome!
See also:
<faa...@startifact.com> wrote:
> Hi there,
>
> I ran into this recently to try to trigger Chrome Frame. In the end I
> went with sending a response header instead instead of going for meta,
> but before that I hacked up this strategy:
>
> I used fanstatic.register_inclusion_renderer to register a bogus
> extension (.xua, say) with a particular renderer and a very low order
> (you can make it negative). The lower order makes this inclusion be
> sorted high up.
>
> The renderer doesn't actually do anything with its URL argument, but
> instead just returns a snippet of HTML with the X-UA-Compatible meta
> header in it.
>
> You need to then register a resource for your app with that extension
> .xua. It needs to have a file present that isn't actually used (as you
> don't refer to using your snippet), but to please Fanstatic.
>
> After this I got the meta header appear above everything else. It
> still didn't trigger Chrome Frame properly but that was possibly due
> to other issues. :)
>
> We need to have a simpler way to support this kind of stuff in
> Fanstatic though; perhaps a way to explicitly control that Fanstatic
> should insert only under existing link tags or script tags. Proposals
> and patches are welcome!
https://bitbucket.org/fanstatic/fanstatic/issue/65/support-for-entries-that-must-go-before
Kit Blake said that fanstatic should render the inclusions just before
the closing element of the <head> section, instead of at the start.
Would anybody object to rendering the inclusions at the </head>?
Cheers,
JJ
Martijn Faassen
May 23, 2013, 7:00:16 AM5/23/13
to fans...@googlegroups.com, Thierry Florac
Hi there,
On Thu, May 23, 2013 at 12:48 PM, Jan-Jaap Driessen
<janjaap...@gmail.com> wrote:
> Kit Blake said that fanstatic should render the inclusions just before
> the closing element of the <head> section, instead of at the start.
> Would anybody object to rendering the inclusions at the </head>?
I'm trying to recall why I didn't do that in the first place. I can't
think of any good reason not to have the default behavior be at the
end of the </head>.
Besides changing the default, it would be good in general to have it
configurable somehow where inclusions get added.
Regards,
Martijn
On Thu, May 23, 2013 at 12:48 PM, Jan-Jaap Driessen
<janjaap...@gmail.com> wrote:
> Kit Blake said that fanstatic should render the inclusions just before
> the closing element of the <head> section, instead of at the start.
> Would anybody object to rendering the inclusions at the </head>?
think of any good reason not to have the default behavior be at the
end of the </head>.
Besides changing the default, it would be good in general to have it
configurable somehow where inclusions get added.
Regards,
Martijn
Jan-Jaap Driessen
May 25, 2013, 3:37:54 AM5/25/13
to fans...@googlegroups.com, Thierry Florac
On Thu, May 23, 2013 at 1:00 PM, Martijn Faassen <faa...@startifact.com> wrote:
> I'm trying to recall why I didn't do that in the first place. I can't
> think of any good reason not to have the default behavior be at the
> end of the </head>.
I included this change in the 1.0a2 release of fanstatic.
> I'm trying to recall why I didn't do that in the first place. I can't
> think of any good reason not to have the default behavior be at the
> end of the </head>.
Thierry, does this solve your issue?
Warning: This change may break your code, but it is probably a good
idea to include the resources at the end of the <head>.
> Besides changing the default, it would be good in general to have it
> configurable somehow where inclusions get added.
Martijn, it would be cool if we could pair on this.
Thierry Florac
May 25, 2013, 6:08:41 AM5/25/13
to Jan-Jaap Driessen, fans...@googlegroups.com, Thierry Florac
Le Sat, 25 May 2013 09:37:54 +0200,
Jan-Jaap Driessen <janjaap...@gmail.com> a écrit:
> On Thu, May 23, 2013 at 1:00 PM, Martijn Faassen
> <faa...@startifact.com> wrote:
> > I'm trying to recall why I didn't do that in the first place. I
> > can't think of any good reason not to have the default behavior be
> > at the end of the </head>.
>
> I included this change in the 1.0a2 release of fanstatic.
>
> Thierry, does this solve your issue?
Can't test for it before next sunday.
I'll give you a feedback as soon as possible...
Regards,
Thierry
Jan-Jaap Driessen <janjaap...@gmail.com> a écrit:
> On Thu, May 23, 2013 at 1:00 PM, Martijn Faassen
> <faa...@startifact.com> wrote:
> > I'm trying to recall why I didn't do that in the first place. I
> > can't think of any good reason not to have the default behavior be
> > at the end of the </head>.
>
> I included this change in the 1.0a2 release of fanstatic.
>
> Thierry, does this solve your issue?
I'll give you a feedback as soon as possible...
Regards,
Thierry
Reply all
Reply to author
Forward
0 new messages