I've made some test on my system (Linux Debian + GNOME (with network-manager to manage proxy settings) + Oracle Java 7)
(and some tests with java 6 (without dynamic keys)

Test page: https://libcloud.apache.org/getting-started.html

* Firefox (Iceweasel) : OK
SSL warning is display, after accept, https elements are recording.

(but: 2 or 3 samples with
javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
    at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
    at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1822) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1004) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:820) at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at org.apache.jmeter.protocol.http.proxy.HttpRequestHdr.parse(HttpRequestHdr.java:117)
    at org.apache.jmeter.protocol.http.proxy.Proxy.run(Proxy.java:195)
in view Results Tree (under Proxy recorder)

* Chrome (proxy settings with network manager) : OK
SSL warning is display, after accept, https elements are recording.

* Epiphany (Web browser include with GNOME) : OK
Without warning message, all HTTPS urls are loaded (with the temporary certs) (apache.org, twitter, google elements)


==

In the special case when it's a java 6 runtime env and the HTTPS domains field is disabled, we should perhaps add some tool tip text in label/field to help the user to understand why the field is disable. (I will make this)

Milamber


Le 10/09/2013 01:52, sebb a ecrit :
Testing help still needed!

On 6 September 2013 23:09, sebb <[email protected]> wrote:
The Proxy server can now record embedded resources when used on Java 7.

It creates a CA and keystore as needed.

More work is needed:
- creating certs is fairly slow, so it would help if these were set up
before the test started.
This is now done in ProxyControl when the start button is pressed.

- the CA cert is not created until the first SSL request is received,
so the first browser request will fail. The certificate can then be
loaded and the recording restarted. This needs to be fixed
This has been fixed as above; pressing Start creates the CA if necessary.

The CA cert can now be installed before starting the recording.

- documentation
That still needs to be done, but it would help to know whether the
code works for others, not just on my system.

Initialising the keystore
---------------------------------
Ideally the CA cert needs to be created before the test starts, so it
can be loaded into the browser. However not all recordings use SSL, so
it seems wasteful to create the keystore if it won't then be used.

Also, creating additional host entries is quite slow, so it would be
useful to be able to specify these in advance.

One possible approach would be to add a new field to the GUI (Global
Settings has room) where the user could list the hosts/domains they
intend to test. [This would also signal that SSL proxying is required]
When the Proxy is started, it could then create the keys if necessary.
This would also create the certificate ready for the browser to load.
That has been implemented.

Note that Start can now take a minute or two the first time it is used.

Domains would be indicated by a leading "*." - e.g. *.apache.org.
It would be easy to match a host against a domain.
This would get round the issue that converting from host to domain is
tricky to do programmatically (there are lots of special cases).
Whereas the user presumably has a pretty good idea what domains they
are testing.
That has been implemented.

I hope to make a start on improving the code in a day or two; in the
meantime if there are any issues/suggestions please raise them here.
Feedback needed on the latest version.

Does it work OK for you?
What does not work well?
Are there any blockers (apart from docs) that mean it could not be
used for the next release of JMeter?


Reply via email to