I encountered this problem today when upgrading from WSO2 ESB 4.5.1 to 4.7.0. I had another problem with 4.5.1 that I had to upgrade because of, so upon encountering this problem with 4.7.0, I had no choice but to solve it.
After thinking for some time, I remembered that the default transport was switched from NHTTP to Passthrough in 4.6.0 to increase performance. 4.7.0 ships with configurations for both, but with PT enabled by default. The config files are in the axis2 directory:
${carbon.home}/repository/conf/axis2/
The PT config file is axis2_pt.xml
. The NHTTP one is axis2_nhttp.xml
. You can diff them to get an idea of what changes; the diff is luckily pretty clean.
You can easily switch from PT to NHTTP by modifying the main config file:
${carbon.home}/repository/conf/carbon.xml
There you have the <ConfigurationFile>
element under <Axis2Config>
. The default file, axis2.xml
seems to be more or less a copy of axis2_pt.xml
. To switch to NHTTP, just change the <ConfigurationFile>
to ${carbon.home}/repository/conf/axis2/axis2_nhttp.xml
.
Switching to NHTTP solved my problem of ESB 4.7.0 not dealing with 100 CONTINUE correctly. Specifically, I was trying to upload a PDF using curl through the ESB to another service. Using PT, it failed; using NHTTP, it worked fine. My obvious conclusion is that PT is simply buggy in this scenario.
From the reading that I have done about PT vs NHTTP, the only "official" side-effect of switching from one to the other is that PT should be faster in certain scenarios. However, NHTTP has been around for longer and is therefore likely to be a bit more solid simply by virtue of having gone through more bugfixing rounds. I don't know this for sure as I'm not involved with the development of WSO2 ESB, but it's an educated guess. :)
Also I'd love to comment on Isuru Perera's answer, but I don't have the necessary reputation so I'm afraid I have to put my two cents regarding https://wso2.org/jira/browse/APIMANAGER-1007 here. This issue does indeed seem related - especially based on my own experience with curl today - but unfortunately the kind folks at WSO2 have resolved the issue as "Not a bug" after a number of comments that ultimately recommended avoiding the use of curl because other clients "work as expected," thus rendering this a "curl issue." IMHO having broken behaviour with HTTP-spec-compliant requests is not a client issue and should be resolved. This effectively renders the PT transport unusable in certain scenarios - i.e. ones where the client is a little bit more intelligent about how it POSTs large bodies. This is really a shame, because scenarios where the request body does not need to be parsed are precisely what the PT transport was designed for and where it should excel!
Oh and this is my first post on stackoverflow so I'm sorry if I've broken any house rules; I've been a passive participant for some time so I'm hoping I didn't do anything too wrong!