We Keep Coding

Tomcat 7 , Spring rest template application producing err_invalid_chunked_encoding in browser

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

DWR SecurityException : HttpSessionId is blank in POST request

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.

Getting SSL error when tring to hit a REST webservice(GET call)?

my team is facing a SSLException when we try to hit a REST based webservice. We are adding all the headers required to call the webservice.
Right now we have got a temporary solution to the problem. We have added the security file from Java 8 folder to the Java 7 folder.
There is one more socket based solution which our team tried, but I don't know it on the larger context. But it has been refused to implement too by higher authorities.
We have found that the webservice is based on java 5. And in java 7 some of the security certificates were not available due to which we were getting an error. The first solution works for the testing phase but it's not good for production purposes.
The actual error we are facing is:
javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
During our research we found this question too and tried to follow up every solution given for this question.
So is there anyone who has faced the similar issue before and provide us with a solution to apply, so that we can hit the webservice and add those certificates dynamically at runtime.

Please post the SSL debug logs?
I had this problem once and reason was that remote rest service were only supporting TLSv1.2 and we were on TLSv1.1
We called the rest service by mentioning TLSv1.1 protocol in System.setProperty() method.

The problem was with the Java version. The security files which were needed by the rest service to hit were not present in Java 1.7.51(our current java version). So instead of changing the security files we upgraded our java version from 1.7.51 to 1.7.80(This version of java contains those security files). Hence no compatibility was broken and the issue was fixed successfully without a workaround.
We got this solution's idea from this StackOverflow Question.

Constant warning when running tomcat from intellij

All of a sudden, when i run tomcat from within intellij, the output console is constantly bombarded with messages.
(very) short video showing this:
http://screencast.com/t/ddBhIh3UZiA
The messages constantly output is:
16:05:31,157 WARN http-nio-8222-exec-1 servlet.PageNotFound:198 - Request method 'HEAD' not supported
16:05:31,158 WARN http-nio-8222-exec-2 servlet.PageNotFound:1120 - No mapping found for HTTP request with URI [/] in DispatcherServlet with name 'dispatcher'
I am using Spring 4.1 and tomcat 8.
Java 8 and Windows 8.1
This phenomenon didnt use to happen before and it suddently started occuring. What is going on?

I'm having the exact same problem. If you have your Tomcat run configuration set to open a browser on launch, IntelliJ will try to ping the website to ensure it's up prior to opening the browser. I believe it's doing HEAD requests and since your site isn't set to answer / HEAD requests, you get the error.
Unchecking the "After launch" checkbox under "Open browser" in the server tab of the run configuration fixed it for me.
As for getting JetBrains to fix this, I'm not sure what to do about it. I did just upgrade to 14.0.3 so that might be the cause...

Solved by JetBrains in this ticket, and if you want you can change a Jar to avoid the regression.
https://youtrack.jetbrains.com/issue/IDEA-135196

It seems your client is using HEAD has the request method. It is similar to GET but it says to the server that it must not return message-body in the response.
Either check your pages or client for HEAD requests or accept HEAD as RequestMethod like this:
#RequestMapping(method = {RequestMethod.GET, RequestMethod.HEAD})

JAX-WS Endpoint to Domino

My Domino Web Service Provider broke when I upgraded the (Win64) server from 8.5.3FP2 to FP3. I wrote some information about it to XPage forum.
Instead of fighting with Axis based legacy stuff I'd like to use JAX WS which comes with Java 1.6. I decided to try this very simple example. I copy pasted the code to a Java project on my Designer Eclipse, run it and the Web Service was up and running on my local machine: it responded and returned the WSDL.
Next I copy pasted the code to an NSF on server as Code/Java elements and changed:
public static void main(String[] args)
to
public HelloWorldPublisher()
and called this constructor from SSJS in XPage. I got this error:
Exception in thread "main"
com.sun.xml.internal.ws.model.RuntimeModelerException : A
#WebService.targetNamespace must be specified on classes with no
package. Class: HelloWorldImpl
The classes were in packages. I run it also with command line on Domino server JVM and got the same error. After googling I added this
#WebService(targetNamespace="http://mycompany.net/dev/ph")
to HelloWorld and
#WebService(endpointInterface="com.mkyong.ws.HelloWorld", targetNamespace="http://mycompany.net/dev/ph", portName="HelloWorldPort", name="HelloWorld", serviceName="HelloWorldService")
to HelloWorldImpl in NSF and run it. After that the web service seemed to be up and running!
Next I booted the server because it was slow and after that I have not seen the WSDL! I've run the code many times, restarted HTTP and tried removing #WebService attributes. I've also tried to run the code with command line on server again but that gives me always the above #WebService.targetNamespace error, I have no idea why.
Now I get always this to Domino console:
java.lang.NoClassDefFoundError: com.sun.xml.internal.ws.api.streaming.XMLStreamWriterFactory
(initialization failure) at
java.lang.J9VMInternals.initialize(J9VMInternals.java:140) at
com.sun.xml.internal.ws.server.SDDocumentImpl.writeTo(SDDocumentImpl.java:266)
at
com.sun.xml.internal.ws.transport.http.HttpAdapter.publishWSDL(HttpAdapter.java:538)
at
com.sun.xml.internal.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:230)
at
com.sun.xml.internal.ws.transport.http.server.WSHttpHandler.handleExchange(WSHttpHandler.java:107)
at
com.sun.xml.internal.ws.transport.http.server.WSHttpHandler.handle(WSHttpHandler.java:92)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:77) at
sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:77) at
com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:80) at
sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:569)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:77) at
sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:541) at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919)
at java.lang.Thread.run(Thread.java:738)
when accessing this URL on server:
http://localhost:9999/ws/hello?wsdl
I'm a bit surprised I get anything to Domino log because I think this uses JVM http server. I don't understand why it worked first and now it cannot find this class.
How do I publish JAX WS endpoint to Domino Server?
EDIT
I downloaded the JAX WS jars from here:
http://jax-ws.java.net/
and placed the them in \jvm\lib\ext folder. The WSDL URL started to work again! Also the endpoint URL has some information now. I don't know why I had to do this because the functionality should be included in JVM 1.6. Next I will try to use Domino objects in the endpoint code.
Is it possible to make JAX WS to use Domino http server?
thanks,
Panu

JAX-WS is already included in Notes/Domino. I suspect there may have been some instability introduced within your server whilst you were round-tripping during development.
I've created custom providers and consumers within XPages applications c/w SSJS and Custom Java access without issue since 8.5.3 and in 9.0.
Are you past your issue now? (if so, can you close out this question accordingly please :-)