Bug 1330487 - JBoss Web org.apache.coyote.http11.Http11Protocol.COMPRESSION not working as expected
Summary: JBoss Web org.apache.coyote.http11.Http11Protocol.COMPRESSION not working as ...
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web, Documentation
Version: 6.4.7
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: ---
Assignee: Andrea Hoffer
QA Contact: Pavel Slavicek
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-26 10:58 UTC by Jan Stourac
Modified: 2019-08-02 07:33 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-02 07:33:32 UTC
Type: Bug


Attachments (Terms of Use)

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.


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