We Keep Coding

Gzip compression not working in my project with Spring boot 1.5.10.RELEASE

I am using Spring Boot 1.5.10.RELEASE version. Gzip compress not working.
http://localhost:9000 --> http://localhost:8080/api/..
Angularjs & rest api on different Port. Enabled CrossOrigin to accept request from angularjs ui.
Using embedded tomcat server to deploy spring boot application.
Not using http2 property i.e. server.http2.enabled=true
Angualrjs calls rest api. Following is $http service
$http({
method: method,
url: url,
params: params,
data: body,
headers: {
Authorization: token,
"Content-type": 'application/json'
}
});
Rest api response size Approx 25 MB so I want to compress response.
I have added well known property in application.properties to apply gzip compression.
Spring boot 1.5.10 Supported properties
# Enable response compression
server.compression.enabled=true
# The comma-separated list of mime types that should be compressed
server.compression.mime-types=text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json
# Compress the response only if the response size is at least 1KB
server.compression.min-response-size=1024
I have observed network tab and no observed Content-Encoding: gzip in response header.
Request
Request URL: http://localhost:9081/employee
Request Method: GET
Status Code: 200
Remote Address: [::1]:9081
Referrer Policy: no-referrer-when-downgrade
Response Header
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://localhost:7000
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: application/json;charset=UTF-8
Date: Sun, 28 Jun 2020 18:15:17 GMT
Expires: 0
Pragma: no-cache
Set-Cookie: JSESSIONID=6E7C07874D0329E18A0C07E5E303F005; Path=/; HttpOnly
Transfer-Encoding: chunked
Vary: Origin
X-Application-Context: application
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Request Header
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Authorization: Bearer eyJhbGciOiJIUzINiJ9.eyJyb2xlIjiU0VDVE9SSEVBRCIsImxldmVsRG93biI6IkVENzA0MTI7TU04MzcyNDtKTDgzNTwO0RNNDAwNzE7Skc3MzA0NjtFQzM0NjEzO05OMTY5Nzk7QUs2MDYzNztTVDE4NTg4O0FTMjczNTE7Q0I4MTg3OTtWQTc4MTk5O0NNOTM3MDA7QVkyMzYzNztKUzcwMDY4O0NCMTc2NzE7TksyMTU2MDtMUzg4OTg0O0FQNTg3MDg7VFcyjk0NTtKSzI1Nzc3O01TNDk5MjE7SkI4OTcyOTtNSDAyMTI3O01CMTUwODk7SU0xMjgwODtNQzcxOTc2O1JSMjAzMDI7TFM1ODk4MiIsImxldmVsVXAiOm51bGwsImRlbGVnYXRlZCI6bnVsbCwic29lSWQiOiJTUjQ0MTg1I0.*************
Cache-Control: no-cache
Connection: keep-alive
Content-type: application/json
Host: localhost:9081
Origin: http://localhost:7000
Pragma: no-cache
Referer: http://localhost:7000/build/standalone.html
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36
I am not getting following expected headers in response header
Content-Encoding: gzip
Vary: Accept-Encoding
Any changes require at client /server side ?
---[Edit-1] -------------
Tried gzip in individual project which worked but not worked in my project.
Following is response header when invoke rest api from browser
Content-Encoding: gzip
Content-Type: application/json;charset=UTF-8
Date: Sun, 28 Jun 2020 18:12:29 GMT
Transfer-Encoding: chunked
Vary: Accept-Encoding
-----[Edit-2]-----Ziplet----
Using ziplet dependency I am able to compress response, but I want to use spring boot gzip compression.
Response header - when used Ziplet
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://localhost:7000
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Encoding: gzip
Content-Type: application/json;charset=UTF-8
Date: Mon, 06 Jul 2020 18:31:07 GMT
Expires: 0
Pragma: no-cache
Set-Cookie: JSESSIONID=8465D2E81A1A9CE146255B6C545FBE30; Path=/; HttpOnly
Transfer-Encoding: chunked
Vary: Accept-Encoding
Vary: Origin
X-Application-Context: application
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
When used ziplet - I can see
CompressingFilter : CompressingFilter has initialized
When using Spring boot gzip compression not observed anything where I can assume gzip compression enabled.
Any property to debug spring boot gzip compression with embeded tomcat ?
like logging.level.org.eclipse.jetty.server.handler.gzip=TRACE
How can i verify server.compression.enabled ?
Any changes require at client /server side in my project?
Thanks in advance.

As your question, you are using Spring Boot 1.5.10.RELEASE.
For that version of the framework, the class TomcatEmbeddedServletContainerFactory is responsible for starting the embedded Tomcat container.
The source code of that class and version can be found here:
https://github.com/spring-projects/spring-boot/blob/v1.5.10.RELEASE/spring-boot/src/main/java/org/springframework/boot/context/embedded/tomcat/TomcatEmbeddedServletContainerFactory.java
In this class, you can find the method customizeCompression:
private void customizeCompression(Connector connector) {
ProtocolHandler handler = connector.getProtocolHandler();
if (handler instanceof AbstractHttp11Protocol) {
AbstractHttp11Protocol<?> protocol = (AbstractHttp11Protocol<?>) handler;
Compression compression = getCompression();
protocol.setCompression("on");
protocol.setCompressionMinSize(compression.getMinResponseSize());
configureCompressibleMimeTypes(protocol, compression);
if (getCompression().getExcludedUserAgents() != null) {
protocol.setNoCompressionUserAgents(
StringUtils.arrayToCommaDelimitedString(
getCompression().getExcludedUserAgents()));
}
}
}
Try setting a breakpoint on this method and debug your application to see if compression is actually enabled.
If not, it is very likely that there is some kind of wrong configuration in your project.
If it works, it indicates that your configuration is correct and that the problem is different.
If this is the case, before looking at anything else, it might be appropriate to try another server, such as Jetty or Undertow, which also support this compression feature, and see if everything works correctly there.
For instance, to configure Undertow instead of Tomcat you can use the following:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-undertow</artifactId>
</dependency>
You can try to configure Tomcat compression programmatically as well; see matsev's answer in this stackoverflow question:
Using GZIP compression with Spring Boot/MVC/JavaConfig with RESTful

You have to enable http2 support in your spring boot properties
server.http2.enabled=true
And then try

Spring-Boot how to disable "Transfer-Encoding: chunked" in java

I have a problem with tomcat included with spring boot. i want to disable the chunked encoding or even using the HTTP 1.0 version as it doesn't use it. i don't have a java class for that i just want to change the properties.
below the part of the HTTP response header that i received with the chunked encoding
HTTP/1.1 200
Date: Thu, 26 Sep 2019 15:46:57 GMT
Content-Type: application/xml;charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive

JAX-WS issuing GET then GET and POST

I wrote a JAX-WS client using classes generated from wsimport to invoke a webservice. To test my client locally, I wrote an implementation of the webservice and published it locally and called it. Everything worked as expected.
One thing I noticed is that my client connects to the endpoint and issues a GET followed by another connection with a GET against the endpoint looking for the wsdl, and finally issues the POST with my payload in the same connection.
Here is the tcpmon output (edited to protect the guilty):
GET /someWS HTTP/1.1
User-Agent: Java/1.7.0_03
Host: 127.0.0.1:9877
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
----------------------------------
GET /someWS?wsdl HTTP/1.1
User-Agent: Java/1.7.0_03
Host: 127.0.0.1:9877
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
POST /someWS HTTP/1.1
Accept: text/xml, multipart/related
Content-Type: text/xml; charset=utf-8
SOAPAction: "document/http://someUrl"
User-Agent: JAX-WS RI 2.2.4-b01
Host: 127.0.0.1:9877
Connection: keep-alive
Content-Length: 610
<Valid Soap message here/>
Is this standard behaviour or I have messed something up? I am using JAX-WS RI 2.2. This works fine locally, but a certain production WS is quite unhappy with the initial GET request and throws a 500 and I was hoping that I could suppress the GET requests and just skip to the POST.

The client is not caching the wsdl file locally and hence you will see a GET request before every POST. The GET is for getting the wsdl file and the POST is for the actual web service request. Ask the client to cache the wsdl locally and refer to it.

Upload files with metadata, Azure JAVA API

I am trying to upload a file with certain METADATA to an azure blob container.
When I do it with the .net SDK it simple sends one put and all metadata as it should be.
However, if I try with Java it sends 3 puts and the metadata won't be reflected until I issue a cBlockBlob.uploadProperties() command, and until the 3rd put.
Why is it going through 3 puts? is it an issue in the JAVA sdk?
This is the 1st put
*PUT /mycontainer/0721ef8f-8d70-4b91-9d1f-04757363f903.xml?blockid=AAAAAEm%2FC%2FE%3D& comp=block&sr=c&timeout=4&si=WriteOnly& sig=eUe%2Fe7kcFcmiIzOVNgqbXd%2BjlIN3ZQd8fkQq3IsHQVQ%3D HTTP/1.1
x-ms-version: 2011-08-18
User-Agent: WA-Storage/Client v0.1.1
Content-Type:
Host: certainhost.blob.core.windows.net
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 4613*
This is the 2nd put
*PUT /mycontainer/0721ef8f-8d70-4b91-9d1f-04757363f903.xml?comp=blocklist&sr=c&timeout=4&si=WriteOnly&sig=eUe%2Fe7kcFcmiIzOVNgqbXd%2BjlIN3ZQd8fkQq3IsHQVQ%3D HTTP/1.1
x-ms-version: 2011-08-18
User-Agent: WA-Storage/Client v0.1.1
Content-Type:
Content-MD5: hYRJFeM5RFH29bPj3oxhwA==
Host: certainhost.blob.core.windows.net
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 100*
<?xml version='1.0' encoding='UTF-8'?><BlockList><Uncommitted>AAAAAEm/C/E=</Uncommitted></BlockList>
This is the 3rd put (the one that shows required metadata)
*PUT /mycontainer/0721ef8f-8d70-4b91-9d1f-04757363f903.xml?comp=properties&sr=c&timeout=4&si=WriteOnly&sig=eUe%2Fe7kcFcmiIzOVNgqbXd%2BjlIN3ZQd8fkQq3IsHQVQ%3D HTTP/1.1
x-ms-version: 2011-08-18
User-Agent: WA-Storage/Client v0.1.1
Content-Type:
x-ms-blob-content-encoding: utf-8
x-ms-meta-x-ms-meta-versionCFDI: 3.2
Host: certainhost.blob.core.windows.net
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 0*
and this is the only put in .net SDK
*PUT /mycontainer/0721ef8f-8d70-4b91-9d1f-04757363f903.xml?comp=properties&sr=c&timeout=4&si=WriteOnly&sig=eUe%2Fe7kcFcmiIzOVNgqbXd%2BjlIN3ZQd8fkQq3IsHQVQ%3D HTTP/1.1
x-ms-version: 2009-09-19
User-Agent: WA-Storage/6.0.6002.18312
x-ms-blob-type: BlockBlob
x-ms-meta-versionCFDI: 3.2
Host: certainhost.blob.core.windows.net
Content-Length: 6841
Connection: Keep-Alive*
Something else, what does this mean?
<?xml version='1.0' encoding='UTF-8'?><BlockList><Uncommitted>AAAAAEm//E=</Uncommitted></BlockList>
It is sent in the second put, .net won't show it.

I believe what's happening is that JAVA SDK is splitting your file into blocks and uploading those blocks. The first PUT request a "PUT Block" request and the second one is the "Commit Block List" request and the 3rd one is the "Set Metadata" request. Based on the REST API documentation, you can set a blob's metadata during "Commit Block List" operation as well (http://msdn.microsoft.com/en-us/library/windowsazure/dd179467.aspx). It does seem odd that .Net SDK uploads this file in just one request while Java SDK splits the file in blocks and upload it. I wouldn't be surprised if this is how it is implemented in Java SDK. What's the size of the file which you're trying to upload?
Regarding your 2nd question, that's the payload for "Commit Block List" operation.

Is there a way in CXF to disable the SoapCompressed header for debugging purposes?

I'm watching CXF service traffic using DonsProxy, and the CXF client sends an HTTP header "SoapCompressed":
HttpHeadSubscriber starting...
Sender is CLIENT at 127.0.0.1:2680
Packet ID:0-1
POST /yada/yada HTTP/1.1
Content-Type: text/xml; charset=UTF-8
SoapCompressed: true
Accept-Encoding: gzip,gzip;q=1.0, identity; q=0.5, *;q=0
SOAPAction: ""
Accept: */*
User-Agent: Apache CXF 2.2
Cache-Control: no-cache
Pragma: no-cache
Host: localhost:9090
Connection: keep-alive
Transfer-Encoding: chunked
I'd like to turn SoapCompressed off in my dev environment so that I can see the SOAP on the wire. I've searched Google and grepped the CXF source code, but don't see anything in the docs or code that reference this. Any idea how to make the client send "SoapCompressed: off" instead, without routing it through Apache HTTPD or the like? Is there a way to configure it at the CXF client, in other words?

A grep of the CXF codebase doesn't yield "SoapCompressed" at all. I really don't think it's CXF that is sending that. The Accept-Encoding thing is also suspect as that is only sent if you enable the GZIP interceptors. Is it possible that the proxy thing you are using is adding it?

The client for org.apache.cxf.jaxrs.client.AbstractClient has points where you set the headers in a key-value map (Map). "SoapCompressed", "false".