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));
Related
I'm uploading a screenshot failure png to Test Rail via their API - Here's the code that works in 106:
Request = new RestRequest("/index.php?/api/v2/add_attachment_to_result/85)
.AddHeader("Content-Type", "multipart/form-data")
.AddFile("attachment", "C:\Source\screenshot.png");
IRestResponse AddAttachmentResponse = Client.Post(Request);
The only thing I changed after the upgrade to v107 is the last line:
RestResponse AddAttachmentResponse = Client.PostAsync(Request).GetAwaiter().GetResult();
I now get an error back from the Test Rail API "Bad Request" - here's the documentation on their API: Test Rail Add Attachment API doc - I know the http engine has changed in 107 - what do I need to do differently now?
UPDATE:
It appears that v107 is not sending the Content-Type in the header - here's the output from HttpTracer:
==================== HTTP ERROR REQUEST: [POST] ====================
Authorization: Basic TokenRemoved
Accept: application/json, text/json, text/x-json, text/javascript, *+json, application/xml, text/xml, +xml, *
User-Agent: RestSharp/107.1.1.0
Accept-Encoding: gzip, deflate, br
Cookie: tr_session=7cef485e-1aca-46bb-a773-9d9f5d410ee6
--8eef1c58-a3df-4ddb-a1c5-e081ccf90709
Content-Type: application/octet-stream
Content-Disposition: form-data; name=attachment; filename=Untitled.png; filename=utf-8''Untitled.png
snipped for brevity
Note there is a Content-Type in the body, but none in the header.
Issue link: https://github.com/restsharp/RestSharp/issues/1713
As we discussed, HttpTracer only shows the request headers, and Content-Type is the request header.
When debugging this issue (and a couple of other related issues), we found out that the issue was caused by the server not being able to handle name and filename parameters in the form part (Content-Disposition header) if they are not wrapped in quotes. Strangely enough, adding content disposition directly using ContentDispositionHeaderValue doesn't add quotes by default. After adding them manually it started to work:
fileContent.Headers.ContentDisposition = new ContentDispositionHeaderValue("form-data") {
Name = $"\"{file.Name}\"",
FileName = $"\"{file.FileName}\""
};
My answer is for anyone who experienced a similar issue with 107.1, the latest alpha and the next stable version should handle this properly.
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.
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).
I just want to make sure I have no issue here. Does anybody know what causes the
2017-03-17 07:59:17.5838|1|Microsoft.AspNetCore.Hosting.Internal.WebHost|INFO|Request starting HTTP/1.1 GET http://192.168.20.57:8081/hardware/configuration/active application/json
2017-03-17 07:59:17.5868|4|Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware|DEBUG|The request path /hardware/configuration/active does not match a supported file type
I'm exposing the Web API by Kestrel only (no IISIntegration).
The request header contains
GET /hardware/configuration/active HTTP/1.1
Accept: application/json, text/plain, */*
Content-Type: application/json
Defining
[Produces("application/json")]
explicitly in my controller has no effect.
Set StaticFileOptions.ServeUnknownFileTypes to true:
app.UseStaticFiles(new StaticFileOptions()
{
FileProvider = new PhysicalFileProvider("mypath"),
ServeUnknownFileTypes = true // <<<<<<
});
or find out where the unknown types can be extended (please let me know in the latter case).
After the request comes in by kestrel (which is your first log row).
It first goes through a middleware pipeline until it reaches the WebApi middleware.
As you can see in the second logging row: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware. It reached the StaticFileMiddleware and not the WebApi Middleware.
Probably the staticFileHandler finds a file there in the wwwroot folder and thus returns this message? Or Even before it tries to check the filesystem it checks if it is an allowed/known file extension and this is not the case, thus this second log message.
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