I'm using IBM Websphere 7 and am running into a problem when I try to add a value to the http header (X-UA-Compatible : IE=edge,chrome=1). It is telling me that the response has already been committed and the value cannot be added. If there is a configuration that you could setup in Websphere 7 to automatically add this to the response header that would be perfect.
The solution that I came up with was to create a filter that would execute early on in the processing of the request. That filter would add the values to the response header. It's a workaround and wasn't exactly what I was looking for, but it works for now.
Related
I have a servlet which uses Apache Http Client to make requests to a third party. This has worked for years, but I am adding a new third party that I call via the existing servlet. It is failing (404) from the servlet but works fine using command line curl from the same machine.
The really weird thing is it works against this third party's sandbox system, both from curl and from the servlet. The only difference I see in the curl output between the two cases is how the 100 Continue is returned from the third party server. When I call the sandbox server (which also works from Http Client) the headers returned look like:
< HTTP/1.1 100 Continue
< HTTP/1.1 200
When I call the test/QA system (which works from curl but not from Http Client) the equivalent lines are
< HTTP/1.1 100
< HTTP/1.1 200
As you can see, the one which works returns 100 Continue while the one which doesn't work just returns 100. As I understand it, including the message as part of the status is recommended but optional, so this is standard compliant. And I am not getting an exception, I am getting a 404 page with an HTML body which does clearly come from this third party.
I have tried activating the "wire" logging (as per their documentation - we are using log4j so added it to the existing properties file) but don't get any extra logging at all. This is why am I using curl to try and see a difference in how the third party reacts.
I tried disabling the whole 100-continue (.setExpectContinueEnabled(false) when building my RequestConfig) but it didn't help (curl also works without the 100-continue)
Does the Apache Http Client fail in some weird way if the 100 doesn't include the message? Or am I focussing on totally the wrong place?
(We are using 4.5.x branch of Apache Http Client still - I upgraded to latest 4.5.13. I can try the 5.x.x series but that would impact a lot more I guess)
It turns out the client does handle the 100 without a message fine.
The issue was a third part that worked for https://api.example.com/foo but gave 404 for https://api.example.com:443/foo! Don't ask...
The curl command included the port but curl must have stripped it out as it was the standard one. Changed my servlet to do that and it worked.
I have the error :
java.lang.NullPointerException
When i want to add a view result in tree for a post http request.
Here is what i did :
I have the last version (5.0) and i am using fedora 28. And that my first time using apache Jmeter (i read this post but that say that i have to upgrade to 2.0 but i am in 5.0)
Is that a bad configuration that i did ? Or a fedora bug ? ..
My expectation is that you need to remove the tick from the Use multipart/form-data box
If you have this enabled - JMeter sends a multipart request and your server might fail to handle it.
Also looking into the nature of your request my expectation is that you should send Content-Type header with the value of application/json. This can be done via HTTP Header Manager:
In case of further issues please update your question with the relevant part of jmeter.log file
I have a Tomcat 7 , Spring 4.2 'RestController' implementation of REST API which seems to produce 'ERR_INVALID_CHUNKED_ENCODING' for few API calls on returning a JSON response.
It is the same code that creates a ResponseEntity. But for few API calls the "Content-Length" is set properly and other calls the "Transfer-Encoding" is set as Chunked.
private CacheControl cacheControl = CacheControl.noStore().mustRevalidate();
protected <T> ResponseEntity<TNRestResponse<T>> createEntity(TNRestResponse<T> res) {
return ResponseEntity.ok().cacheControl(cacheControl).body(res);
}
The weird part is the response for the same API call that creates ERR_INVALID_CHUNKED_ENCODING seems to work fine in another environment. The only difference is the client and service is running in the same server in the problematic scenario.
The solution already tried is to set the Content-Length manually which seems to result to premature end of file on the client.The JSON length is only around 468 characters but client receives only 409 characters , even though server logs shows that the full response has been sent and connection is closed.
We are so lost at the solution for this problem because it is the same code acting strangely in different environment.I tried to check the compression settings in server.xml on both the tomcat.But everything looks fine.
Also disabled the proxy setting in both IE and chrome.
Any helpful inputs or insights would be really good ? Thanks in advance.
Follow these steps:
1) Go to your OS's Control panel > internet options > Connections >
LAN Settings or to your browser settings.
2) Deselect "Use Proxy" for your LAN or for your browser.
ERR_INVALID_CHUNKED_ENCODING
Original answer
Another original answer
I am trying to upgrade Tomcat 5.5 + JDK 5 to Tomcat 8.5.x + JDK 1.7
The application that is deployed on this server is a legacy application which uses FTL (2.3.4) + DWR(2.0.3) + Spring (2.5.5) frameworks
When deployed on Tomcat 8.5.6 + JDK 7 I am getting errors on few actions which perform POST request from the application.
Most of these actions are DWR calls for filtering/manipulation of data displayed on the screen.
There is a popup message "Session Error" displayed on screen.
On front end profiling I found that the complete error is a SecurityException which results into SessionError.
Session Error - SecurityException
When debugged on server side I found out that the request was being treated as a CSRF attack and hence this exception was thrown.
DWR checks for the HTTP session ID in the body of the POST request to validate the request against CSRF possibility.
So in front end debugging I found that the request is not sending the httpSessionId in the POST body.
Request header and body are as shown here.
I have tried disabling the crossDomainSessionSecurity parameter in DWR servlet initialization.
It works fine after that, but I cannot go ahead with the security risk it poses in the production environment.
Due to this issue I am not able to go ahead with the Tomcat migration.
Please suggest how can I resolve this issue?
I was checking for some new features in Tomcat 8.
I read that from Tomcat 6 onwards Tomcat allows only HTTP requests by default.
Which means that the useHttpOnly flag is true by default.
This causes the javascript requests to fail.
In the deployment I tried by setting the useHttpOnly=”false” and the application works fine after that.
I will do more tests on my side, so for now we can consider this issue to be resolved.
i am working on java with Netbeans IDE and glassfish 3.1.2 i have created in rest services using jaxrs. when request from client is made ,i need to send json data in compressed format.to do this i have enabled the compression in glassfish as shown the following picture
but response got from the server is not compressed using gzip. it is receiving as normal json data. what should i do to overcome this issue
This is a solution for GF 3.1.2.2.
Responses to HTTP requests in version 1.0 are not compressed. You must send your requests in HTTP 1.1 to get gzipped responses from your glassfish server.
More over, you must add the header "Accept-Encoding: gzip" in your http requests.
To get a compressed response you need to have both sides agree to use it. You have configured GlassFish to send compressed responses. I can see that from the picture.
You need to make sure that your request to the services tells GlassFish that it can accept a compressed response. You normally do this by adding the following header to your HTTP requests: Accept-Encoding. You can read about the header in the RFC document that defines HTTP 1.1 request headers.
You can also get a lot of info from reading though SO questions about Accept-Encoding.