Bug 1330487

Summary:	JBoss Web org.apache.coyote.http11.Http11Protocol.COMPRESSION not working as expected
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Jan Stourac <jstourac>
Component:	Web, Documentation	Assignee:	Andrea Hoffer <ahoffer>
Status:	CLOSED EOL	QA Contact:	Pavel Slavicek <pslavice>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	6.4.7	CC:	rmaucher, sjay
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-08-02 07:33:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Jan Stourac 2016-04-26 10:58:02 UTC

Description of problem:
In documentation - Administration Guide [1], there is documented system property:

org.apache.coyote.http11.Http11Protocol.COMPRESSION

How I understand this should work from this documentation is:

off   - default, no compression is performed
on    - response compression is enabled conditionally (therefore when client send http header "Accept-Encoding: gzip"
force - response compression is forced even when client do not provide "Accept-Encoding" http header

Although this works actually quite different for me:

off   - OK; no compression
on    - FAIL; no compression whether client use "Accept-Encoding" http header or not
force - FAIL; now server response is compressed when client uses "Accept-Encoding" http header but uncompressed when no such header is provided by client.

Version-Release number of selected component (if applicable):
EAP 6.4.7


How reproducible:
Always

Steps to Reproduce:
1. start EAP
2. configure system property:
 /system-property=org.apache.coyote.http11.Http11Protocol.COMPRESSION:add(value=on)
3. restart the server
4. perform request to server and see that no compression takes action
 $ curl -D /tmp/headers -H "Accept-Encoding: gzip" http://localhost:8080; cat /tmp/headers
 $ curl -D /tmp/headers http://localhost:8080; cat /tmp/headers

5. now set "force" value
 /system-property=org.apache.coyote.http11.Http11Protocol.COMPRESSION:remove()
 /system-property=org.apache.coyote.http11.Http11Protocol.COMPRESSION:add(value=force)
6. restart server
7. see that compression takes action when "Accept-Encoding" http header is provided by client but not otherwise

Actual results:
When setting system property org.apache.coyote.http11.Http11Protocol.COMPRESSION value to:

- on: then no response compression takes place at all
- force: then compression takes place only in case that client provides "Accept-Encoding" http header

Expected results:
- on: compression takes place in case client provide "Accept-Encoding" http header
- force: compression takes place always (even when client do not provide "Accept-Encoding" http header)

Additional info:


[1] https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.4/html-single/Administration_and_Configuration_Guide/index.html

Comment 1 Jan Stourac 2016-04-26 11:24:22 UTC

Ok, I've just realized one important thing - there is also property "org.apache.coyote.http11.Http11Protocol.COMPRESSION_MIN_SIZE" which is by default set to 2048 Bytes. During my testing recently I used default content page, whose response size is only 1496 Bytes.

Therefore I have done another testing with COMPRESSION_MIN_SIZE set to "1200". Here are results:

- on: this value now seems to be working just fine - when client provides "Accept-Encoding" header in request then response is compressed, otherwise response is uncompressed

- force: this behaves same way as value "on" now (compressed response only when client provides "Accept-Encoding" http header). But there is one difference - now it does not matter how big the response is (does not matter value of COMPRESSION_MIN_SIZE property).

Therefore "force" value works like this: It forces compression for any response size but only in case that client sends "Accept-Encoding" http header. Is this actually correct behaviour?

If I have misunderstood the way the "force" value should work, I think it should deserve better explanation in documentation.