Dave Woodman

Hi Michael, That would seem to be a good approach, I agree

Would GraalVM (https://www.graalvm.org/) be of assistance here? "It is designed for applications written in Java, JavaScript, LLVM-based languages such as C and C++, and other dynamic languages. It removes the isolation between programming languages and enables interoperability in a shared runtime." Dave

Would GraalVM (https://www.graalvm.org/) be of assistance here? It is designed for applications written in Java, JavaScript, LLVM-based languages such as C and C++, and other dynamic languages. It removes the isolation between programming languages and enables interoperability in a shared runtime. Dave

That one resolves the issue - no more 100-continue :-) Thank you

Thank you for your help. The back-end in this case is OpenESB (open-esb.net), which uses Apache Grizzly. Judging from the network traces is it not implemented since there is no response at all sent from the server. The original request does not contan the Expect: 100-continue header, this being added by tamacat-httpd - this is true even with the new jar provided. When using the new jar I receive a 400 error with "BAD REQUEST." I have a question pending whether OpenESB contains support for 100-continue,...

Thank youj for taking the time to look into this. I have tried both work-arounds you provide in the latest released version of tamacat-httpd. I regret that neither seem to work for me - I have Expect: 100-continue in the traffic, no matter which I use, or even if I use both.

Adding to the above, there are various parties that do not support Expect: 100-continue. Can this behaviour be made optional?

Hi, These packets we excluded by the display filter I used since I had other traffic on the system at the time. I have re-captured the transaction on the system when it was quieter, and attached the image showing the capture and the display filter. There is no capture filter in use, so no packets are being excluded at the capture level. Java version in use 1.8.0_191 From the capture, the connection is opened immedately, and the headers sent in a packet with PSH ACK containing an "Expect: 100-continue."...