Bug 851670 - Login into Business central blocked when using mod_jk load balancer
Login into Business central blocked when using mod_jk load balancer
Status: ASSIGNED
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: 3rd Party (Show other bugs)
BRMS 5.3.0.GA
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Maciej Swiderski
Jiri Locker
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-24 12:26 EDT by Jiri Locker
Modified: 2012-10-26 08:17 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
When accessing business-central via Mod_jk load balancer, an exception occurs during Resteasy HttpServletDispatcher service() method and the login process is not completed. The exception is raised in the Resteasy code when the request's content-type header is processed, because this header contains the wrong value. This issue only presents when using Firefox 7 and above, and can be avoided by open the configuration panel of FireFox (In the address bar type about:config). Accepting the warning. Searching for network.http.accept-encoding, and changing the default value (gzip, deflate) to *;q=0.1,gzip,deflat.
Story Points: ---
Clone Of:
Environment:
RHEL5 (for BRMS) Fedora 17 (for EWS) OpenJDK 6 BRMS 5.3.0-P01 standalone EWS 1.0.2 Firefox 7+ (including 10 and 14)
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
server-gzip.log (299.36 KB, text/plain)
2012-08-24 12:26 EDT, Jiri Locker
no flags Details

  None (edit)
Description Jiri Locker 2012-08-24 12:26:56 EDT
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
Comment 2 Maciej Swiderski 2012-09-03 13:14:40 EDT
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
Comment 3 Maciej Swiderski 2012-09-04 05:09:18 EDT
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.
Comment 5 lcarlon 2012-09-18 22:40:01 EDT
I've added the issue and the work around under doc_type known issue to be included in the release notes.

Lee

Note You need to log in before you can comment on or make changes to this bug.