Not entirely a new feature. just give out more control  to user for current xslt module. about when or when not to use current xslt module.<br><br>It doesn&#39;t seems necessarily to me, to fork a new module to publish<br>
<br><div class="gmail_quote">On Wed, Jan 27, 2010 at 6:52 PM, Marcus Clyne <span dir="ltr">&lt;<a href="mailto:ngx.eugaia@gmail.com">ngx.eugaia@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<div class="im"><br>
<br>
tOmasEn wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Maybe not many people using xslt as main web layout. but I do.<br>
<br>
This patch is similar to gzip_disable.  xslt_enable only enable xslt transform for certain user agent.<br>
<br>
e.g.<br>
xslt_enable &quot;Googlebot&quot;<br>
will only enable xslt transform output for google&#39;s crawler.<br>
<br>
And, I&#39;m also planing some other improve on xslt module. Like: when xslt transform failed, output original xml file instead of 500 server error; Skip xslt transform if client send specified HTTP header like &quot;No-XSLT&quot;, etc. Should I talk to somebody and discuss the architect?<br>

</blockquote></div>
If you&#39;re just adding new features, you&#39;re probably better off putting it in a separate module and publishing that.<br>
<br>
Marcus.<br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://nginx.org/mailman/listinfo/nginx" target="_blank">http://nginx.org/mailman/listinfo/nginx</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Tomasen<br><a href="http://twitter.com/ShooterPlayer">http://twitter.com/ShooterPlayer</a><br><a href="http://t.sina.com.cn/Tomasen">http://t.sina.com.cn/Tomasen</a><br>