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.

Forbidden error when I access HTTP and HTTPS URLs

I have a website (Liferay portal 6.1 and Tomcat 7.0) which is having HTTP and HTTPS URL like below.
https://stackoverflow.com/questions/ask
https://stackoverflow.com/profile
I follow below steps and I am getting Forbidden error:
I fill some form details in 2nd URL.
Before submitting that form I open 1st URL in a new tab.
Then if I come back to 1st URL and do a submit then I found a forbidden error.
I checked JSESSIONID at both tabs, Ids are same. What may be the issue? Any idea guys?

It's not worth investing time in making http/https mixed mode work (in my opinion). Bite the bullet and just go https always. Even if you'd fix this issue now, chances are that you'll run into more issues later, eating up more of your time. And when you run into other issues, they're highly likely security sensitive.
Do yourself a favor - unconditionally redirect ALL http traffic to https. It's 2016, there's nothing unusual with this any more.
Edit after your comment: Do this especially if it's an old system (by the way, this was obvious when you mentioned Liferay 6.1. Assuming you're using CE, it's long out of updates): Configure the use of https anywhere you can easily get your hands on. Unconditionally add the HSTS header to take care of the rest. No need to touch any ancient logic. E.g. set
web.server.protocol=https
in your portal-ext.properties. Add the HSTS header to your Apache httpd unconditionally (assuming you have Apache httpd, otherwise use this Liferay App from yours truly).

Error pages in Grails app hosted using IIS 7 / Tomcat connector

I have a Grails application that is running in Tomcat 7 under IIS 7, using the Jakarta Isapi Tomcat connector version 1.2.30 and I'm having trouble getting the error handling to behave how I'd like. The Tomcat connector is configured in uriworkermap.properties to forward all requests below the application's URL to Tomcat:
/OrderSubmission/* = worker1
The Grails application has its own custom error pages which work fine when the application is running on a development machine without IIS / the Tomcat connector, but when on the server, if custom error pages are switched on in IIS, these always override the ones in the Grails application. This means that where I have a specific page to handle a certain exception type, e.g. in UrlMappings.groovy:
"500"(controller: 'error', action: 'itemNotFound', exception: ItemNotFoundException)
...I'm instead seeing the static 500 error page that I've pointed IIS at.
If I instead turn on detailed errors in IIS I get the correct error pages through from my Grails application - however, if a request is made for a URL outside of the application's context, I then see the detailed IIS 404 page, which is unacceptable. If I change the Tomcat connector's uriworkermap.properties to include everything from the root downwards then I instead see a default Tomcat 404 error page. I've tried getting the Tomcat connector to default to custom pages by setting the error_page option in isapi_redirect.properties to point to my IIS static custom pages like so:
error_page=/%d.htm
...but this doesn't work, and I can't find any example of using this setting anywhere.
What I need to happen is for the custom Grails error pages to be shown - unless the URL being requested is outside the application or the application is down, at which point I need custom static error pages to be shown.
Has anyone managed to achieve this?
TIA

I ended up making my error page controller methods return a status of 200 (OK), unless dealing with an AJAX request:
class ErrorController {
def pageNotFound() {
if (!request.xhr){
response.status = 200
}
}
}
IIS is set to 'Custom error pages'.
This prevents IIS stepping in and providing the custom static pages that I provide, unless the requested URL is outside the scope of the Grails application.
The error status is retained for AJAX requests in order to allow the caller to properly deal with the result.
I'm unsure whether it's satisfactory practice to return 200 from the application on error, particularly with regard to search engines - however it seems that even without this change, when an error occurs and the response is ultimately returned to the browser from IIS it has a status of 200, according to Fiddler.

Jersey version downgrade stops connections from working

We had to downgrade our Jersey version from 1.7 to 1.0.3.1 due to the client using Java 5 (and 1.7 did not seem compatible). When using 1.7, we were able to happily connect to the server using the code snippet below. When we downgraded, we only get Error 500s (via a UniformInterfaceException) yet the URL in the error message still works within my browser.
This is our first time working with Jersey - were any major changes made to how URLs are called from 1.0.3.1 to 1.7? Should we change the way we make these types of calls?
WebResource service = client.resource(CPC_SECURE_BASE_URL); //base URL is the server's URL
System.out.println(service.path("customer").path("0007023210").accept(
MediaType.TEXT_XML).get(String.class));
Full stack trace:
com.sun.jersey.api.client.UniformInterfaceException: GET https://<address removed>/app/customer/0007023210 returned a response status of 500
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:563)
at com.sun.jersey.api.client.WebResource.get(WebResource.java:179)
at com.jersey.client.RestClient.retrieveXMLResource(RestClient.java:66)
at com.jersey.client.RestClient.main(RestClient.java:91)
Update - I just tried running the code with Jersey 1.2 (as it is the last version that will run on Java 5) and I now get an Error 401 returned. I have confirmed that everything is still working with Java 6+Jersey 1.7.

Well you're using a different call than I've used before. I've had to downgrade before, and everything transferred a-okay, but my call looked more like my answer for this question.

Coding errors were entered into the application during the downgrade. Hopefully this question can be deleted.