Moving the rest of this work to

This is becoming a slightly bigger issue.

I'm aiming to write a requirements/design document over the next week. But meantime
I'll pour my ideas about requirements in here. I'm hoping ti hear disagreement or other suggestions.

• Need to be able to test arbitrary versions of jetty in out testbed and integration tests (so not special case just for 9.2 9.3)

• Are quite at liberty to rototil the ebmedded/jetty-base so long as we respect and protect the idp.ini file.

• Want as much common code between testbed/integration tests and embedded jetty installs.

• Must continue to run the war from the classpath (so not need to run mvn before running the test bed)

• (I) Want to stop running idp.home from the classpath (or at least not directly), it saves us from checking in our test config [Suggested solution is to run the installer before running the testbed to update any new files, with the option to blow away the existing config first]

• remove dead code (like all the slash conversion stuff)

• If it can be done for free, test Tomcat in the testbed

• If it can be done for free, test IdP 2 in the testbed

IIRC the Jetty config is all merged into a couple of big files, that needs to be undone and the delivered files used, along with a supplemental module for the back channel portion.

Fixing the keystore requires creating a custom jetty-ssl-context file that sets TrustStoreType to the value of the jetty.sslContext.keyStoreType property.

Scott, whenever you have a chance : roughly what needs to be done regarding PKCS12 and Jetty 9.3.2 ?

That's the first obstacle to testing Jetty 9.3.2 via the testbed/integ tests, assuming that's why the testbed says "Invalid keystore format".

9.3.0 does not exhibit the POST error.

I tracked down the regression in 9.3.1, which was that they now defer to a method in the HttpConfiguration class to determine whether a form submission should be parsed (allowing more than POST or PUT to be configured if desired). The bug is that in 9.3, the TLS HttpConfiguration is created by copying the non-TLS HttpConfiguration object, and that copy constructor was broken and did not copy all the members over. As a result, the list of methods to parse bodies for was empty in the TLS config and so the body is silently dropped.

In 9.3.2, they fixed the copy constructor so it works again. If 9.3.1 had to be made to work by somebody, it can be done with manual manipulation of jetty-ssl.xml to set the method collection explicitly.