Patient is a virtual for debuging and solving problem
So I was closely monitor the apache log and noticed the avatar upload action seems to be failing. After further testing, recipe image upload also not working. Ewwwwww…
Avata upload feature can be found everywhere in normal webapps. But the backend is little complicated than it seems. We don’t want one web server serving both static and dynamic content as static content might uses up and ties up the available processes. That’s especially true for file uploading.
So we split things up – serve all static content and cgi using front end apache, while still proxying the rest of requests to the backend application server.
But that’s troublesome to setup and we tried multiple solutions. here a sample config:
<Location />
ProxyPass http://backend:8888/app/
ProxyPassReverse http://backend:8888/app/
</Location><Location /upload>
SetHandler cgi-script
Options +ExecCGI
</Location>
The problem here is that all requests are routed to the backend no matter what the Location directive order is. After few times of rereading the apache doc, we gave up and try to work around it by putting the upload script on a different vhost. Problem seemed to be resolved and We were happy until the avatar upload is failing. To summary the cause, JS cross site scripting.
Unwilling to dive into js cross site scripting issue, I am determined to find a solution in apache. After few hours of googling and asking in forum and irc, eventually I read about exclamation point in ProxyPass from a post. Go back the doc again.
The ! directive is useful in situations where you don’t want to reverse-proxy a subdirectory.
Ha. That’s my solution! Why didn’t I read it more carefully? ProxyPassMatch Directive also comes to handy. Just make sure the exclusions come before the general ProxyPass directive and In my case, outside of the Location / block.
So now cgi and static content are served by yummytime.com from the frontend apache.
avatar and recipe image upload bug gone! Sorry for the wait, now please upload 
