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.
Related
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.
What is the easiest way to either configure Axis2 or extend the message listener to PREVENT any and all information regarding system from returning to the calling client?
An example of what I'm trying to prevent is as follows: Someone sends an improper soap request with some weird stuff in the header and the server responds:
HTTP/1.1 500 Internal Server Error
Date: Wed, 19 Nov 2014 13:12:34 GMT
Server: Apache
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.2.2 Java/Oracle Corporation/1.7)
Connection: close
Content-Length: 465
Content-Type: text/xml;charset=utf-8
...
<faultstring>javax.xml.stream.XMLStreamException: DOCTYPE is not allowed</faultstring>
What is the best way to prevent all of that information from being delivered back to the client? The glassfish messages can be turned off in GlassFish as answered below. I should have been more specific I want to set it up so that any and all exceptions never reach the client. I want to somehow force axis2 to use a generic message instead of returning an Exception. Is it possible to do this with Axis2?
You can add a
-Dproduct.name="".
in your JVM Option for suppressing the X-Powered-By
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 want to fetch a web page from a ASP.NET site that is only accessible from within a session. I'm using Apache HttpClient. I first open the main page of the site, then I search for the link to the "goal" page, and then I fire up a GET request for the "goal" page. The problem is that when I get the response for the second GET request, I always get the same (first) page. If I open the site with Firefox or Google Chrome I get the "goal" page.
From the first response from the server I get the following headers:
HTTP/1.1 200 OK
Date: Sun, 12 Dec 2010 19:03:56 GMT
Server: Microsoft-IIS/6.0
Platform: Mobitel Pla.NET
Node: 4
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
Set-Cookie: ASP.NET_SessionId=0vpgd055cifko3mnw4nkuimz; path=/
Cache-Control: no-cache, must-revalidate
Content-Type: text/html; charset=utf-8
Content-Length: 7032
I inspected the traffic with WireShark and all headers look OK. I send the correct cookie back to the server on the second GET request.
I'm using Apache HttpClient. I have only one instance of DefaultHttpClient and I reuse that for the second request. I have BROWSER_COMPATIBILITY Cookie Policy.
Any ideas?
You need send back this header from the client (send back the cookie you received) in all your further requests:
Cookie: ASP.NET_SessionId=0vpgd055cifko3mnw4nkuimz; // and all other cookies
That should do the trick
I found my stupid mistake.
The mistake was that I was sending the second GET request to a link, without replacing the ampersand character codes.
Ex:
/(0vpgd055cifko3mnw4nkuimz)/Mp.aspx?ni=1482&pi=72&_72_url=925b9749-b7c7-4615-9f1a-9b613c344c82
That is wrong, because I send & instead of &
The RIGHT way to do it is:
/(0vpgd055cifko3mnw4nkuimz)/Mp.aspx?ni=1482&pi=72&_72_url=925b9749-b7c7-4615-9f1a-9b613c344c82