It doesn't seem possible to assign a compressor or intercept to the TRESTClient.
If I set TRESTRequest.AcceptEncoding to 'gzip, deflate' I receive a gzip encoded response from a server that supports gzip.
However, in TIdHTTP I think it would automatically decode it. In TRESTResponse.Content it is still gzip encoded and I have to decode it manually with TIdCompressorZlib.DecompressGZipStream(). Is there a way for TRESTResponse to decode it automatically?
It's native if you set property TCustomRESTRequest.AcceptEncoding with "gzip, deflate" value.
Related
I am trying to consume a REST service using TRestClient but I believe there is an issue with the boundary string for multipart content.
I am capturing the body of the request I am sending, and this is the content type header:
Content-Type: multipart/form-data; boundary=-------Embt-Boundary--07CC944C29DA577E
Then, this is the first section of the multipart form:
-----------Embt-Boundary--07CC944C29DA577E
Content-Disposition: form-data; name="file"; filename="ce.csv"
Content-Type: text/csv
And this is how it ends:
---------Embt-Boundary--07CC944C29DA577E--
I don't think this is an issue on the server, as even my proxy is not able to parse the body:
When I compare this same request vs postman, I notice that the starting and ending boundaries do not match!
Starting: -----------Embt-Boundary--07CC944C29DA577E
Ending: ---------Embt-Boundary--07CC944C29DA577E--
I found that the boundary generation is done in TMultipartFormData.GenerateBoundary() from System.Net.Mime:
When checking the starting and ending boundaries from postman, they match, so I am almost sure this is the issue. I don't think it is related to my code, but let me know if you need it.
I'm trying to send json data as a response body in grails. I've tried setting the Content-Type header to application/json using the following methods:
render (status: httpServletResponse, text: responseToRender as JSON, contentType: "application/json")
Each time the resulting header is as follows:
Content-Type: application/json;charset=utf-8
How do I get rid of the charset=UTF-8 postfix?
You can not get rid of the charset postfix.
You can change it with the charset parameter defined here:
https://docs.grails.org/latest/ref/Controllers/render.html
You can also provide no information by just handing json to render, such as:
response.setContentType("application/json")
render JsonOutput.toJson(responseToRender);
However, this will default to the standard encoding required by HTTP 1.1 which is ISO-8859-1. therefore your result would be application/json;charset=ISO-8859-1
https://www.w3.org/International/articles/http-charset/index.en
So, if you somehow need to use this parameter, you may use .split(";")[0] to access only the first part.
What is the default character encoding for sent requests in Wildfly?
Setting the encoding in contentType header of a request would insure that it will be used?
Thanks,
Tiberiu
You are talking about two different encodings
Request encoding: This is the encoding of parameters in the URL for example. By default is UTF-8 but if you want to change it to ISO-8859-1 (for example) it can be done with <http-listener url-charset="ISO-8859-1" .../> in your configuration file under the undertow subsystem.
Content Type encoding: This is the encoding that you are saying your files have and this is controlled by Content-Type http header and the charset parameter. Content-Type: text/html; charset=ISO-8859-1
On Net::HTTP.Get request to a URL with accept-encoding header set as gzip, how do I check if the response is gzipped, before calling Zlib unzipping on it?
Found the answer, doing a response['Content-Encoding'] returns gzip if the response is Gzip encoded and nil otherwise. Discovered the param value by inspecting the browser HTTP response headers.
I have an NSURLConnection and in didReceiveResponse I'm checking [response expectedContentLength] and getting really large values like 18446744073709551615. There's no way this is correct. The download is about 3k bytes, and when I expect the same request in fiddler, I see a (correct) content length header in the response of about 3k bytes.
To avoid this problem, set header field "Accept-Encoding" to #"gzip;q=0". that tells the server that you do not accept gzip, and will if possible send uncompressed.
The answer, related to the comments, is that it's because the result is gzip encoded. Oddly, the value for the expectedContentLength seems to be junk, and cannot be trusted. If the result is gzip encoded, then NSURLConnection cannot properly determine the size of the unencoded result.