Author: buildbot
Date: Wed Nov 11 21:19:52 2015
New Revision: 972137
Log:
Production update by buildbot for tapestry
Modified:
websites/production/tapestry/content/cache/main.pageCache
websites/production/tapestry/content/https.html
Modified: websites/production/tapestry/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/tapestry/content/https.html
==============================================================================
--- websites/production/tapestry/content/https.html (original)
+++ websites/production/tapestry/content/https.html Wed Nov 11 21:19:52 2015
@@ -125,7 +125,7 @@ public class ProcessOrder
configuration.add(MetaDataConstants.SECURE_PAGE, "true");
}
</pre>
-</div></div><p>With no colon, the meta data applies to the entire application
(including any component libraries used in the application).</p><h2
id="HTTPS-BaseURLSupport">Base URL Support</h2><p>When Tapestry switches back
and forth between secure and unsecure mode, it must create a full URL (rather
than a relative URL) that identifies the protocol, server host name and perhaps
even a port number.</p><p>That can be a stumbling point, especially the server
host name. In a cluster, behind a fire wall, the server host name available to
Tapestry, via the <code>HttpServletRequest.getServerName()</code> method, is
often <em>not</em> the server name the client web browser sees ... instead it
is the name of the internal server behind the firewall. The firewall server has
the correct name from the web browser's point of view.</p><p>Because of this,
Tapestry includes a hook to allow you to override how these default URLs are
created: the BaseURLSource service.</p><p>The default implementatio
n is based on just the getServerName() method; it's often not the correct
choice even for development.</p><p>Fortunately, it is very easy to override
this implementation. Here's an example of an override that uses the default
port numbers that the <a class="external-link"
href="http://jetty.codehaus.org/jetty/" rel="nofollow">Jetty servlet
container</a> uses for normal HTTP (port 8080) and for secure HTTPS (port
8443):</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+</div></div><p>With no colon, the meta data applies to the entire application
(including any component libraries used in the application).</p><h2
id="HTTPS-BaseURLSupport">Base URL Support</h2><p>When Tapestry switches back
and forth between secure and unsecure mode, it must create a full URL (rather
than a relative URL) that identifies the protocol, server host name and perhaps
even a port number.</p><p>That can be a stumbling point, especially the server
host name. In a cluster, behind a fire wall, the server host name available to
Tapestry, via the <code>HttpServletRequest.getServerName()</code> method, is
often <em>not</em> the server name the client web browser sees ... instead it
is the name of the internal server behind the firewall. The firewall server has
the correct name from the web browser's point of view.</p><p>Because of this,
Tapestry includes a hook to allow you to override how these default URLs are
created: the BaseURLSource service.</p><p>The default implementatio
n is based on just the getServerName() method; it's often not the correct
choice even for development.</p><p>Fortunately, it is very easy to override
this implementation. Here's an example of an override that uses the default
port numbers that the <a class="external-link"
href="http://www.eclipse.org/jetty/" rel="nofollow">Jetty servlet container</a>
uses for normal HTTP (port 8080) and for secure HTTPS (port 8443):</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"> public static void
contributeServiceOverride(MappedConfiguration<Class,Object> configuration)
{
BaseURLSource source = new BaseURLSource()
@@ -143,7 +143,7 @@ public class ProcessOrder
configuration.add(BaseURLSource.class, source);
}
</pre>
-</div></div><p>This override is hardcoded to generate URLs for localhost; as
such you might use it for development but certainly not in production.</p><h2
id="HTTPS-DevelopmentMode">Development Mode</h2><p>When working in development
mode, the Secure annotation is ignored. This is controlled by the
tapestry.secure-enabled <a href="configuration.html">configuration
symbol</a>.</p><h2 id="HTTPS-ApplicationServerConfiguration">Application Server
Configuration</h2><p>Setting up HTTPS support varies from application server to
application server.</p><ul><li>Jetty:<ul><li><a class="external-link"
href="http://docs.codehaus.org/display/JETTY/How+to+configure+SSL"
rel="nofollow">Jetty 6</a></li></ul></li><li>Tomcat:<ul><li><a
class="external-link"
href="http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html">Version
6.0</a></li><li><a class="external-link"
href="http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html">Version
5.5</a></li></ul></li></ul></div>
+</div></div><p>This override is hardcoded to generate URLs for localhost; as
such you might use it for development but certainly not in production.</p><h2
id="HTTPS-DevelopmentMode">Development Mode</h2><p>When working in development
mode, the Secure annotation is ignored. This is controlled by the
tapestry.secure-enabled <a href="configuration.html">configuration
symbol</a>.</p><h2 id="HTTPS-ApplicationServerConfiguration">Application Server
Configuration</h2><p>Setting up HTTPS support varies from application server to
application server.</p><ul><li>Jetty:<ul><li><a class="external-link"
href="https://wiki.eclipse.org/Jetty/Howto/Configure_SSL"
rel="nofollow">Versions 7, 8 or 9</a></li></ul></li><li>Tomcat:<ul><li><a
class="external-link"
href="http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html">Version
6.0</a></li><li><a class="external-link"
href="http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html">Version
5.5</a></li></ul></li></ul></div>
</div>
<div class="clearer"></div>