Created attachment 606909 [details] server-gzip.log Description of problem: When accessing business-central via mod_jk load balancer, an exception occurs during Resteasy HttpServletDispatcher service() method and the log in process is not completed. The exception is raised in Resteasy code in a point where the request's content-type header is processed and this header contains a wrong value. Actually it contains a value of a different header! (In this case "gzip, deflate" is value of accept-encoding header.) I did some investigation and came to the conlusion that somewhere on the way of processing the request (POSTing the login form or the request after that) the content-type header content is swapped with a different header. Why this is happening I can't explain. Version-Release number of selected component (if applicable): See Environment field. How reproducible: reliably Steps to Reproduce: 1. set up standalone BRMS to bind to external network interface (not localhost) 2. set up a load balancer [1] 3. launch both and try to log into business central using http://localhost/business-central/ (assuming the load balancer is listening on localhost) Actual results: Log in not completed, exception in server log: > java.lang.IllegalArgumentException: Failure parsing MediaType string: gzip, deflate > at org.jboss.resteasy.plugins.delegates.MediaTypeHeaderDelegate.parse(MediaTypeHeaderDelegate.java:42) Expected results: The exception should not occur, logging in should be possible. Additional info: * make sure to use Firefox at least version 7, cannot reproduce with Firfeox 6 and lower, not sure about other browsers * to get the exception without having to set up load balancer enable RequestDumperValve [2] in deploy/jbossweb.sar/server.xml * see attached server log containing the request dump and check the last three requests preceeding the exception for headers [1] https://access.redhat.com/knowledge/docs/en-US/JBoss_Enterprise_Web_Server/1.0/html/HTTP_Connectors_Load_Balancing_Guide/ chapters 2 and 3 [2] http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html#Request_Dumper_Valve
After some investigation it looks to be FireFox issue only. Cannot reproduce it on Chrome or Safari. As described by Jiri content-type header all of a sudden gets value of accept-encoding header. Tried to explicitly set the accept and content-type headers while sending requests from GWT code but that did not make any difference. I suspect it has something to do with automatic redirection done when accessing protected resource of the servlet container: j_security_check There is a workaround that could be applied and I think it is rather safe in terms of not limiting other capabilities of the browser: 1. open configuration panel of FireFox: in url type about:config 2. accept warning 3. search for network.http.accept-encoding 4. change its default value (gzip, deflate) to * After this change you should be able to logon to business-central/jbpm-console via apache and mod_jk
small update: value of network.http.accept-encoding preference in firefox should be: *;q=0.1,gzip,deflate as * only will break compression on web pages. With above value both cases are supported as what it means is that any compression is supported but quality factor for it is lowest possible while gzip and deflate uses default quality factor (1) meaning it is prefered.
I've added the issue and the work around under doc_type known issue to be included in the release notes. Lee