Bug 851670
Summary: | Login into Business central blocked when using mod_jk load balancer | ||||||
---|---|---|---|---|---|---|---|
Product: | [JBoss] JBoss Enterprise BRMS Platform 5 | Reporter: | Jiri Locker <jlocker> | ||||
Component: | 3rd Party | Assignee: | Nobody <nobody> | ||||
Status: | ASSIGNED --- | QA Contact: | Jiri Locker <jlocker> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | BRMS 5.3.0.GA | CC: | kverlaen | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
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: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Jiri Locker
2012-08-24 16:26:56 UTC
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 |