FormDataPart String wrong charset - jersey

I'm stuck with this problem for two days now. The jersey verion is 2.6.
I have enabled the logging of the request by adding a loggingfilter. Which works well.
My rerquest is logged using the right charset:
Content-Disposition: form-data; name="verskomm"
kleine Ă„nderung
Wenn I want to consume this request using #FormDataParam I get
kleine ?nderung
Where can I set the charset which should be used to decode these parts of the request?
I have no influence on the request, as it is made by a third party program.

Related

Spring SOAP Mtom attachment's identifier encoding problem

I created a SOAP client in my Spring Boot (2.5.5) server.
The envelope is marshalled, the communication works, but I have got an error which said I not attached the binary (file) data.
In my log file the soap message has it and there is a binary attachment.
The only strange thing is, in the Include tags href attibute has a %40 character instead of # character like this:
...
<ns2:DocuData xmlns:ns2="namespace 1">
<ns2:fileContent>
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include"
href="cid:946ff3f8-e725-4cca-8108-676403be336f%40domain.hu"/>
</ns2:fileContent>
</ns2:DocuData>
...
In the multipart data section the Content-ID is:
...
------=_Part_1_22457057.1633284795352
Content-Type: application/octet-stream
Content-ID: <946ff3f8-e725-4cca-8108-676403be336f#domain.hu>
Content-Transfer-Encoding: binary
...
content
...
------=_Part_1_22457057.1633284795352--
Is it the cause of the problem? How can I solve it?
Thanks for any help!
It was my fault! I read out the data from the stream when I logged the request in the interceptor. I turned off the logging and the message sent successfully.

Jersey 2.22.1 FileDataMultiPart Header Issue

Hey at the moment i try to upload some files with the jersey client api 2.22.1. I've analyzed the calls of the cms ui to write my own service. For the upload of files i need to generate following request with jersey:
------WebKitFormBoundarydgCBaM6oYnsWZE56
Content-Disposition: form-data; name="contentItem"
{"id":2858,"properties":[{"id":5604,"alias":"dateiHochladen","value":{"selectedFiles":"uploadjava.PNG"}}],
"name":"testcms.PNG","contentTypeAlias":"DateiHochladen","parentId":2857,"action":"publish","expireDate":null,"releaseDate":null,"templateAlias":"DateiHochladen1"}
------WebKitFormBoundarydgCBaM6oYnsWZE56
Content-Disposition: form-data; name="file_dateiHochladen"; filename="uploadjava.PNG"
Content-Type: image/png
------WebKitFormBoundarydgCBaM6oYnsWZE56--
At the moment i am able to generate the upper field, but i am not able to generate the second one with name and filename. Can someone give me a hint how to do this? I've already tried to set new headers, fields, parts and contentdispositions...

valums file-uploader IE and #Responsebody. IE Launches download dialog.

I am using valums file-uploader to upload files. This works great if my Spring controller returns void. If I add a #Responsebody Object to my controller IE things that I am about to download instead of uploading a file and launches a dialog.
The reason I would like to have a #Responsebody Object and not void is for error handling. How can I trick IE in this case?
I'm assuming that Spring is automagically setting the content-type to application/json for you, which will not work in IE. Ensure the content-type of your response is text/plain. Some will say that text/html is correct, and that is true for most cases. However, text/html will cause you problems if your JSON response contains HTML as IE will mess with the response. So, your safest bet is to ensure the content-type of your response is text/plain.
While we are on the topic of IE quirkiness, also be sure that you only return a 200 response if you intend to also include JSON in your response. IE will, by default, replace the content of "small" non-200 responses with a "friendly" message. "Small", I believe, is defined as a response that is less than 512 (or possibly 256) bytes.
For a list of all things you should be aware of when using IE, have a peek at the "limitations of IE" section in the Fine Uploader readme.

WP7 - Prevent RestSharp from caching

I use RestSharp in my Windows Phone 7.1 project.
My problem is RestSharp always cache response data.
Example:
At the first time I send request, it returns data correctly. After some delete operations, I send that request again, but response seems the same as the first time, nothing's changed.
If I stop debugging and press F5 to start again, it works perfectly as expected.
I also tried request.AddParameter("cache-control", "no-cache", ParameterType.HttpHeader); and got no luck.
How can I fix this problem?
I have the same issue so just add header that specify not to cache response data
client is my RestClient with base url and than add default header Cache-Control with value no-cache.
client.AddDefaultHeader("Cache-Control", "no-cache")
I found solution in Rico Suter comment, thanks! I will mark this as accepted anwser
its a hack but try something like url = originalUrl + "&nocache=" + DateTime.Now.Ticks
The "Cache-Control" header should do the trick!
I think HTTP Headers are case-insensitive, but the server may not agree with me there! You should try using Cache-Control instead of cache-control...
Also, I would also add the Pragma header with no-cache value to the request (some old servers don't use the "Cache-Control" header, but they will sure recognize this one)!
And I would try to use Fiddler to debug the comms and check that the headers are really being sent to the server as expected!
Another solution can be to set the "If-Modified-Since" header with value of DateTime.Now:
client.AddDefaultParameter("If-Modified-Since", DateTime.Now, ParameterType.HttpHeader);

Asian characters in IE 8 get garbled in Server; is this due to HTTP header Content-Type?

One of the request parameters in an http request made by the client contains Japanese characters. If I make this request in Firefox and look at the parameter as soon as it reaches the server by debugging in Eclipse, the characters look fine. If I do the same request using IE 8, the characters get garbled when I look at them at the same point in the server code (they are fine in both browsers, though). I have examined the POST requests made by both browsers, and they both pass the same sequence of characters, which is:
%2C%E3%81%9D%E3%81%AE%E4%BB%96
I am therefore thinking that this has to do with the encoding. If I look at the HTTP headers of the request, I notice the following differences. In IE:
Content-Type: application/x-www-form-urlencoded
Accept: */*
In Firefox:
Content-Type application/x-www-form-urlencoded; charset=UTF-8
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
I'm thinking that the IE 8 header doesn't state the UTF-8 encoding explicitly, even though it's specified in the meta tag of the HTML document. I am not sure if this is the problem. I would appreciate any help, and please do let me know if you need more information.
Make sure the page that contains the form has UTF-8 as charset. In IE's case, the best thing to make sure of this is by sending a HTTP header ('Content-Type: text/html; charset=utf-8') and adding a meta http-equiv tag with the content type/charset to your html (I've seen this actually matter, even when the appropriate header was sent).
Second, your form can also specify the content type:
<form enctype="application/x-www-form-urlencoded; charset=utf-8>

Resources