By default axis2 returns regular(plain text xml) response. My goal - find some cfg property to make axis2 return gzipped response.
Anybody?
Thanks!
You configure this via the client, not the server
http://wso2.org/library/230#GZIP
Set this options flag to true
org.apache.axis2.transport.http.HTTPConstants.MC_GZIP_REQUEST
to send your client request gzipped
Set this options flag to true
org.apache.axis2.transport.http.HTTPConstants.MC_ACCEPT_GZIP to request that the server respond with a gzipped response
Related
I'm invoking a HTTP GET request to another system using RESTEasy with resteasy-client:3.12.1.Final (provided by WildFly 20.0.1.Final).
ResteasyClient client = new ResteasyClientBuilder().build;
ResteasyWebTarget target = client.target(fromPath(url));
Response response = target.request()
.header(AUTHORIZATION, "Basic <authentication_token>")
.accept(APPLICATION_JSON)
.get()
As you can see, I don't configure anything "special" in the ResteasyClientBuilder but for some reason all requests contain this header parameter: Accept-Encoding: gzip which causes some trouble on the remote side.
The RESTEasy documentation however states:
RESTEasy supports (though not by default - see below) GZIP
decompression. If properly configured, the client framework or a
JAX-RS service, upon receiving a message body with a Content-Encoding
of "gzip", will automatically decompress it. The client framework can
(though not by default - see below) automatically set the
Accept-Encoding header to be "gzip, deflate" so you do not have to set
this header yourself.
From my understanding the gzip parameter should not be set by default. Or are there any other possible default configurations which might add this parameter?
You might want to try this:
Variant variant = new Variant(MediaType.JSON_APPLICATION, "", "gzip");
Response response = client.target(generateURL("/big/send")).request().post(Entity.entity(b, variant));
I am testing a REST API service that supports json and gzip data. I have tested the response from the json request payload. How to test if it handles gzip data properly? Please help?
Basically the client sends a request with accept-encoding as gzip in the header, service handles the compression and the client takes care of the decompression. But I need a way to confirm that service indeed handles compressed gzip data
gzip is basically a header + deflate + a checksum.
Gatling will retain the original Content-Encoding response header so you can check if the payload was gzipped, and then trust the gzip codec to do the checksum verification and throw an error if the payload was malformed.
Whenever uploading a file (json) to S3 using JMeter's HTTP Request sampler the uploaded file contains the HTTP headers at the top of the file. I am using a signed URL (with actual values):
https://something-s3bucket-something.s3.eu-west-1.amazonaws.com/afda5939-c232-d746-06f7-68790abde85b-91e962d6-4643-8091-fab8-9d0f78f35810.jsonTemp?X-Amz-Expires=18000&x-amz-security-token=somethinglongandcomplicated&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=somethingspecific&X-Amz-Date=20190627T070453Z&X-Amz-SignedHeaders=host;x-amz-security-token&X-Amz-Signature=something
HTTP Request Settings:
Resulting json:
--Y0B3WMeM2M6xYSUHpjPUIj72y3xnO_pswRA12Oh
Content-Disposition: form-data; name="filename"; filename="500payslips.json"
Content-Type: binary/octet-stream
Content-Transfer-Encoding: binary
{
... json content ...
}
}
--Y0B3WMeM2M6xYSUHpjPUIj72y3xnO_pswRA12Oh--
I know I could add the s3 java libraries to JMeter and then code the upload but I would prefer to just simply use the HTTP Request sampler (if possible).
More of a workaround than a fix(?). Instead of sending the file as a multipart/form-data I just read the contents of the file into a variable and sent the content as part of the body of the request.
I'm trying to create an API using Fluentd that receives events via HTTP, parses those events, and then returns the parsed event data to the client in the response.
I have been able to set up the HTTP endpoint in Fluentd and verify that it is receiving data. However, from the documentation, I cannot find a way to return data to the client in the response body.
I'm starting from the standard HTTP example in the Fluentd docs:
<source>
#type http
#id input_http
port 8888
</source>
<match debug.**>
#type stdout
#id output_stdout
</match>
And when I curl the endpoint
curl -i -X POST -d 'json={"json":"message"}' http://localhost:8888/debug.test
this is what I get:
HTTP/1.1 200 OK
Content-Type: text/plain
Connection: Keep-Alive
Content-Length: 0
So the endpoint is working, but I need it to return data to the client.
How could I modify my config to return data in the response, in addition to the status code information? Do I need to add an output or can this be accomplished by modifying the input? Obviously I will need to add a parser or exec filter of some type to modify the data before it is returned, but right now, I am just trying to get it to return the request body.
Fluentd is logs aggregator and collector with inputs, outputs and transformation. It doesn't work as API like you are desiring.
I am attempting to get some headers sent from my server to my front end via a fetch request.
In the controller function, I am explicitly sending some headers like this:
exports.getItems = async (ctx) => {
ctx.set('Search-type', 'category');
};
In postman, when I make a get request to my server I get these headers:
Connection →keep-alive
Content-Length →6442
Content-Type →application/json; charset=utf-8
Date →Thu, 19 Apr 2018 16:10:54 GMT
Search-type →category
However, when I try to access the header in the fetch request from the front end, I can only log the Content-Type. How do I get Search-type from my fetch?
After some googling, I found this issue on github which seems very similar to mine. This led me to another github issue page with the suggestion that I need to 'expose some explicitly needed headers'.
In the koa/cors documentation, there is an option allowHeaders Access-Control-Allow-Headers what I want to know is, how do I expose the headers so I can get them on my front end?
In the response to the GET, in addition to adding the Access-Control-Allow-Origin response header, you also need to include the Access-Control-Expose-Headers: <comma-separated-list-of-headers> response header.
If that header isn't returned by the server, even though the headers are sent by the server to the browser, the browser blocks any non-standard headers from being accessed by JavaScript. So you can see Content-Type (because it's a 'standard' response header), but not Search-type.
Basically, you need to ensure that the server responds with this
Access-Control-Expose-Headers: Search-type
(in addition to any other CORS response headers, like Access-Control-Allow-Origin, of course).