My team and I have a Tomcat server running a Restfull webservice, implemented using RestEasy:
#POST
#GZIP
#Path("/capture")
#Consumes(MediaType.APPLICATION_JSON)
Response RecieveData(#GZIP RecievingData recievingData);
We need to make compressed post to this service. The problem is we are not finding an implementation that works.
We tried using interceptors:
https://hc.apache.org/httpcomponents-client-4.2.x/httpclient/examples/org/apache/http/examples/client/ClientGZipContentCompression.java. But we were unable to capture the POST request Body and compress it.
We tried using the RestEasy client but it doesn´t seems to be compreesing the body of the Post Request: www.posttestserver.com/data/2016/01/06/15.33.391016591335
Finally we tried a customized class: https://gist.github.com/takumakei/913067. But we got a 400 error on the request:
HTTP/1.1 400 Bad Request [Content-Encoding: gzip, Content-Type:
text/html; charset=UTF-8, Date: Thu, 07 Jan 2016 10:07:05 GMT, Server:
Apache-Coyote/1.1, Content-Length: 66, Connection: keep-alive]
We are out of ideas and this supose to be a simple function for an HTTP Client. Any ideas?
OBS: Here is the RestEasy Proxy:
#POST
#GZIP
#Consumes(MediaType.APPLICATION_JSON)
public Response saveData(#GZIP RecievingData customer);
EDIT: Got some changes in the Firewall and the 3rd method changed to an error 400.
If using Tomcat why not add a RequestFilter that will pre-process received requests that contain header Content-Encoding: gzip and decompress it before the rest of the filter chain handles it?
EDIT:
I'm guessing your third option may actually have worked (snoop the network to verify), the issue was you got 403 - Forbidden response from the server. That's a problem with authorization not with the URL, request encoding, or anything else. The GZIP might actually be working for you right now.
EDIT:
Your latest output for HTTP response code 400 - Bad Request shows Content-Type: text/html. The Controller is expecting Content-Type: application/json, so the client did not set the ContentType as required by the Controller. Recheck your usage and config of the client code.
In the end I used the Resteasy framework for server and client to implement the GZIP compression.
Server side:
https://docs.jboss.org/resteasy/docs/2.3.0.GA/userguide/html/gzip.html
Client Side:
https://docs.jboss.org/resteasy/docs/2.2.1.GA/userguide/html/RESTEasy_Client_Framework.html
That worked for me.
Related
I am using Spring Oauth client setup on my frontend. I'm authentication against my API, which returns this
{
error: "unauthorized"
error_description: "User does not exist"
}
using my rest client (Google Plug: Advance RestClient); which is expected.When I use Spring Oauth Client setup, I was expecting that the error object RestClientException would have that JSON result in the response body however it is empty. See attached image (Watch Console shows what's in the response body).
Right click the image and select open image in new tab to make the image bigger
Request sent
grant_type=c_password&username=test&password=test&client_id=test&client_secret=test
Response
Date: Sun, 26 Apr 2015 20:59:45 GMT
Connection: close
Cache-Control: no-store
Pragma: no-cache
Www-Authenticate: Bearer realm="api/", error="unauthorized", error_description="User does not exist"
Content-Type: application/json;charset=UTF-8
Server: Jetty(7.x.y-SNAPSHOT)
Via: 1.1 vegur
Raw
JSON
This may be a RestTemplate bug - your server (or the proxy) is using a combination of Connection: close and no Content-Length headers.
One way to confirm this: make your server write Content-Length headers (in Spring, adding a ShallowEtagHeaderFilter will do that).
If this workaround fixes this, then this bug has been fixed in SPR-8016 - upgrading the client application to Spring 4.1.5 will solve this.
it seems the actual exception that you are getting is not RestClientException. Just debug the error, it would be something HttpClientErrorException. So catch this exception instead of above one. This exception has methods to get the desired result.
I'm using jCryption and JavaCryption, the server-side implementation of the jCryption JavaScript plug-in.
There appears to be an issue with what seems the Java implementation, in that FireFox's firebug is reporting a "not-well formed" error with the JSON that is returned to the client from the server. So, unlike the thread, "not well-formed" error in Firefox when loading JSON file with XMLHttpRequest, this is coming from the response object, NOT the request object.
I tried adding .JSON, application/json as a MIMEtype to my web server, IIS 7.5, but that didn't help. Then I tried .JSON, text/plain and that didn't help, either.
Do I have to edit the Java code to force application/json, when it sends it back to the client? Or, what can I do to resolve this issue?
Thank you for any help.
Here is the raw output for the first one causing the "not-well formed" error:
HTTP/1.1 200 OK
Content-Length: 294
Server: Microsoft-IIS/7.5
X-Powered-By: Nothing
Date: Tue, 23 Oct 2012 02:10:24 GMT
{"e":"10001","n":"b3fbbe3d2e3599e840a117be08f72726d8ee643dada3805ab24b9a9150d123a7a0902ae45f2f2e194e5462c4f5c3b91cca91b48d1f07c6cd7fab629a331148f66516df05dfa0bd95cc9f477069e60fa54eab8a5586d08436717758d9706b90c884eded7260af1ce5ff70f507b9c5ddb019b6e1313a77f4eab3b2d04a09934d8d","maxdigits":"131"}
Here is the second one:
HTTP/1.1 200 OK
Content-Length: 200
Server: Microsoft-IIS/7.5
X-Powered-By: Nothing
Date: Tue, 23 Oct 2012 02:10:24 GMT
{"challenge":"zf6iI5D8hVDCmMVuHIFy71ikKxcqVzkLplMDKP6Hgz7EPv2STfYjcBlf6ep1wu5OMCCsPKf4dRECpVvr7yIK8kCm0I5c4xTXCkmnyyzBXeHgbvkzGWVmaLzxj5RYajdWLFkvN1waV41FhR+PtK1tOmGe8k57wSZ/yyZUAsvh7NaJf6THc9P9rQ=="}
You need to look at what is in the actual response. You need to look at what the responses content-type header currently says, and what the body of the response contains. Firebug can show you both of those.
There is a good chance that the response body is not JSON at all ... but an HTML error report about some problem with the request (as the server sees it).
Either way, you can't resolve the problem properly until you have worked out what is causing it. Simply assuming that it is content type problem is not a sound strategy.
Based on the response you posted, the problem is most likely due to the fact that there is no Content-Type header. If this response comes from Java, then you probably do need to modify the Java (or JSP) to set the missing header in the response.
Set Content-Type to application/json in jsp file
Setting a Content-type header in a servlet.
(There are other ways to do this if it is impossible to change the servlet or JSP code.)
I've replaced the Tomcat by Jetty. Now I have 400 http error code for requests sent by a third party system. As I see, the difference with my tests sent by curl and a web-browser is the url in the http verb:
POST http://10.15.1.9:49302 HTTP/1.0
Host: 10.15.1.9
Content-Type: text/xml
Content-Length: 71065
User-Agent: hpost/0.1
Pragma: no-cache
Accept: */*
this request doesn't work, but post with relative URL such as POST / HTTP/1.0 works fine. Who is wrong? I cannot change the third party system, so, is it possible to make jetty accept such requests?
I've tried Jetty v6.1.26, v7.6.4 and v8.1.4 - works the same.
Ok, I think the reason is missing trailing slash after the url, the POST http://10.15.1.9:49302/ HTTP/1.0 works fine.
Does any body know if it is jetty problem or the client sends malformed url?
While the HTTP spec RFC-2616 says that the server must accept absoluteuri's for the request line, this is generally only used for proxy requests.
To Jetty, the request line POST http://10.15.1.9:49302 HTTP/1.0 is viewed as a HTTP/1.0 request, and fall into the rules of RFC-1945 for Request Line URIs that states absoluteuri's are always Proxy requests.
I've reported the issue, it is fixed now.
I make very simple HTTP server in Java. The response sent to the browser is
HTTP 1.1 200 OK
Server: OneFile 1.0
Content-Type: text/html; charset=utf-8
Content-Length: 202
Transfer-Encoding: chunked
<HTML><HEAD><TITLE>My website</TITLE></HEAD>
<BODY><H1>Document </H1>
</BODY></HTML>
mozilla firefox displays it as text/plain although it should be text/html Why?
I suspect the Setup info is ignored...is it any difference for browser if I make connection on port 8080?
Thanks for any help
The browser will honor your headers. Unfortunately, your response is malformed for several reasons:
the response should start HTTP/1.1, not HTTP 1.1
you specify Transfer-Encoding: chunked, but your response does not follow the chunked format.
It appears that Firefox, quite sensibly, refuses to interpret such malformed response and just shows it unchanged.
Worldpay (The payment processor from RBS) sends a HTTP Post to my website once a payment is accepted. Problem is - the Post isnt getting through and my server responds with one of the following 3 HTTP error's:
HTTP 408 (Timeout)
HTTP 405 (Not allowed)
Invalid status line >NULL<
Now when i Post something to the url from my test php script this works fine which leads me to believe the issue could be with the fact that the Post from them is created by Java:
POST /worldpay_success.html HTTP/1.0
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Host: www.mysite.com
Content-Length: 116
User-Agent: WJHRO/1.0 (WorldPay Java HTTP Request Object)
authAmountString=%26%23163%3B1.99&_SP.charEnc=UTF-8&desc=Test.....etc
Does anyone have any experience with this? After speaking to Worldpay they say my server is responding with a 408 Timeout after 0.1 seconds so it doesnt seem to be properly timeing out... Any help apreciated
Paul
Check 405 Method Not Allowed and Request Timeout. It shouldn't matter if the POST request is created from Java.