WAF issues after updating to 9.709-3

Hi, we have the same issue after updating from 9.708-6 to 9.709-3 (ASG virtual appliance). However, it does not affect our EWS services (don't have hybrid Azure / Exchange infrastructure), but one of our applications:
Customer calls the URL of the application we host, which forwards to the appropriate internal server via WAF. If certain requirements are not met, the application connects to an external third-party system and expects an XML as response. Since the update to 9.709-3, the application receives an HTML with status 500 instead of the required XML, resulting in an application error. Regardless of whether a firewall profile is active or not.
(Also in virtual webserver the status for the real web server is "in error" (yellow), as mentioned by FrancWest. Other web applications / virtual webservers pointing to the same real web server have status "active" (green). By disabling and reenabling the virtual webserver, the status changes to green until the next connection to the URL.)

httpd[55393]: [proxy_http:error] [pid 55393:tid 3776043888] [client xx.xx.xx.xx:44050] AH01086: read less bytes of request body than expected (got 0, expected 418)
httpd[55393]: [proxy_http:error] [pid 55393:tid 3776043888] [client xx.xx.xx.xx:44050] AH10154: pass request body failed to xxx.xxx.xxx.xxx:443 (xxx.xxx.xxx.xxx) from xx.xxx.xx.xxx () with status 500

After restoring the sophos appliance from backup (virtual machine) before the update (back to 9.708-6), it works again.
Possibly the similarity to the problems described here with EWS, since with ews XML is also returned?

Hi, we have the same issue after updating from 9.708-6 to 9.709-3 (ASG virtual appliance). However, it does not affect our EWS services (don't have hybrid Azure / Exchange infrastructure), but one of our applications:
Customer calls the URL of the application we host, which forwards to the appropriate internal server via WAF. If certain requirements are not met, the application connects to an external third-party system and expects an XML as response. Since the update to 9.709-3, the application receives an HTML with status 500 instead of the required XML, resulting in an application error. Regardless of whether a firewall profile is active or not.
(Also in virtual webserver the status for the real web server is "in error" (yellow), as mentioned by FrancWest. Other web applications / virtual webservers pointing to the same real web server have status "active" (green). By disabling and reenabling the virtual webserver, the status changes to green until the next connection to the URL.)

httpd[55393]: [proxy_http:error] [pid 55393:tid 3776043888] [client xx.xx.xx.xx:44050] AH01086: read less bytes of request body than expected (got 0, expected 418)
httpd[55393]: [proxy_http:error] [pid 55393:tid 3776043888] [client xx.xx.xx.xx:44050] AH10154: pass request body failed to xxx.xxx.xxx.xxx:443 (xxx.xxx.xxx.xxx) from xx.xxx.xx.xxx () with status 500

After restoring the sophos appliance from backup (virtual machine) before the update (back to 9.708-6), it works again.
Possibly the similarity to the problems described here with EWS, since with ews XML is also returned?

Hi,

version 9.710 is out. There is no mention about any WAF fix, however maybe you want to volunteer and report.

Since your UTM is virtual an easy rollback, as you described, is possible. 

Firmware Version 9.710-1 does NOT fix the issue. 

Wow! Thank you for testing. Much appreciate your effort. Sadly a negative result, but was worth a try.

Hi, thanks for the hint with 9.710. We'll test in our lab, but it may take some time, since it needs some of our devs involved.
But I don't have big hopes, since M Fuller already tested it with negative result.

9.710 does not fix this issue. I also tested it last week.

We had the same problem with the XML error messages since update to 9.709-3. Here's a workaround that works for us:

Webserver Protection  -> Web Application Firewall -> Real Webservers -> Edit -> Advanced -> select / enable "Disable backend connection pooling"  

I don't see a real connection there, but at least it works for us.

Unfortunately this doesn't work for us. Although the behavior is different when enabling this setting. We now get a 401 unauthorized, instead of the invalid XML error.

I've tried this too and get the same results with the 401.  My Pfsense firewall will be taking over soon.