It's probably using a different verb than POST, but might behave as one. Get an IEHttpHeaders trace. Once you figured out which exact request fails on the server, it's either a question of configuration or a trivial code change in Waffle.

After googling around, I think I know what's going on. I bet the flash client doesn't know how to handle NTLM. You would see a 401 response from the server and the client never sends anything back popping up a message. This
page talks about an update that should fix it.

Yep, your rich-faces client doesn't know how to deal with NTLM (multi-step authentication). It never sends back an Authorization: NTLM ticket the second time around. Talk to the people making the plugin.

I think that you have to either get an upload component that supports NTLM or remove protection from the upload URL (split the site in two). The latter might not be that bad because one of the issues is about how NTLM works. NTLM is a connection-oriented
protocol, you need to re-authenticate per connection. But Tomcat sessions are per client, so you actually are already logged in securely. If you're protecting everything with NTLM you can't fool the browser not to send a first POST with a Content-length: 0,
but if you post to two different destinations it might just work.

I attempted to use two different war deployments within the same application server (JBoss 5). One deployment is through the filter with NTLM, the other is not. This doesn't work because both share the same jsessionid and even though the second
app is not under authentication, the servlet post gets the content blocked. Am I doing this wrong? I'm sure looking for a means to get around this issue.