svn commit: r1530447 - /jmeter/trunk/xdocs/usermanual/component_reference.xml

[se...@apache.org]

Author: sebb
Date: Tue Oct  8 22:28:13 2013
New Revision: 1530447

URL: http://svn.apache.org/r1530447
Log:
Show 2.10 recording information first

Modified:
    jmeter/trunk/xdocs/usermanual/component_reference.xml

Modified: jmeter/trunk/xdocs/usermanual/component_reference.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/component_reference.xml?rev=1530447&r1=1530446&r2=1530447&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/component_reference.xml (original)
+++ jmeter/trunk/xdocs/usermanual/component_reference.xml Tue Oct  8 22:28:13 2013
@@ -5742,8 +5742,29 @@ If any of the browser checks fail, it wi
 <p>
 JMeter needs to use its own certificate to enable it to intercept the HTTPS connection from
 the browser. Effectively JMeter has to pretend to be the target server.
+</p>
+<p>
+For versions of JMeter from 2.10, JMeter will generate its own certificate(s).
+These are generated with a validity period defined by the property <code>proxy.cert.validity</code>, default 7 days, and random passwords.
+If JMeter detects that it is running under Java 7 or later, it will generate certificates for each target server as necessary (dynamic mode)
+unless the following property is defined: <code>proxy.cert.dynamic_keys=false</code>.
+When using dynamic mode, the certificate will be for the correct host name, and will be signed by a JMeter-generated CA certificate.
+By default, this CA certificate won't be trusted by the browser, however it can be installed as a trusted certificate.
+Once this is done, the generated server certificates will be accepted by the browser.
+This has the advantage that even embedded HTTPS resources can be intercepted, and there is no need to override the browser checks for each new server.
+(Browsers don't prompt for embedded resources. So with earlier versions, embedded resources would only be downloaded for servers that were already 'known' to the browser)
+</p>
+<p>
+The JMeter certificates are generated when the proxy is started.
+Certificate generation can take some while, during which time the GUI will be unresponsive.
+The cursor is changed to an hour-glass whilst this is happening.
+When certificate generation is complete, the GUI will display a pop-up dialogue containing the details of the certificate for the root CA.
+This certificate needs to be installed by the browser in order for it to accept the host certificates generated by JMeter; see <a href="#install_cert">below</a> for details.
+</p>
+<p>
 With versions of JMeter up to 2.9, it used a single certificate for all target servers.
-This certificate is not one of the certificates that browsers normally trust, and was not for the
+[Likewise if JMeter is not being run under Java 1.7 or later]
+This certificate is not one of the certificates that browsers normally trust, and will not be for the
 correct host.<br/>
 As a consequence: 
 <ul>
@@ -5780,28 +5801,13 @@ The following properties can be used to 
 <li>proxy.ssl.protocol - the protocol to be used (default "SSLv3")</li>
 </ul>
 </p>
-<p>
-For versions of JMeter from 2.10, if the <code>proxy.cert.alias</code> property is not defined, JMeter will generate its own certificate(s).
-These are generated with a validity period defined by the property <code>proxy.cert.validity</code>, default 7 days, and random passwords.
-If JMeter detects that it is running under Java 7 or later, it will generate certificates for each target server as necessary (dynamic mode)
-unless the following property is defined: <code>proxy.cert.dynamic_keys=false</code>.
-When using dynamic mode, the certificate will be for the correct host name, and will be signed by a JMeter-generated CA certificate.
-By default, this CA certificate won't be trusted by the browser, however it can be installed as a trusted certificate.
-Once this is done, the generated server certificates will be accepted by the browser.
-This has the advantage that even embedded HTTPS resources can be intercepted, and there is no need to override the browser checks for each new server.
-(Browsers don't prompt for embedded resources. So with earlier versions, embedded resources would only be downloaded for servers that were already 'known' to the browser)
-</p>
-<p>
-The JMeter certificates are generated when the proxy is started.
-Certificate generation can take some while, during which time the GUI will be unresponsive.
-The cursor is changed to an hour-glass whilst this is happening.
-</p>
 <note>
 If your browser currently uses a proxy (e.g. a company intranet may route all external requests via a proxy),
 then you need to <a href="get-started.html#proxy_server">tell JMeter to use that proxy</a> before starting JMeter, 
 using the <a href="get-started.html#options">command-line options</a> -H and -P.
 This setting will also be needed when running the generated test plan.
 </note>
+<a name="install_cert"/>
 <h4>Installing the JMeter CA certificate for HTTPS recording</h4>
 <p>
 As mentioned above, when run under Java 7, JMeter can generate certificates for each server.