Develop Reference

file could not be downloaded in IE 11 when a compressed(gzipped) response is sent to the client

I am trying to download a file from an application through two frameworks. one with struts 1(older framework) and the other with Spring MVC(migrated from old).In Spring migrated application it is showing file could not be downloaded in IE 11 when a compressed(gzipped) response is sent to the client. It is showing "File could not be downloaded". It works fine in chrome as well as in older struts framework. Also if the response is not compressed, file gets downloaded successfully on IE as well on Spring MVC. I cannot really identify the cause here. Requesting some guidance and help to identify this problem.
Request headers is
<code>
Request URL: //edited
Request Method: POST
Status Code: 200 / OK
- Request Headers
Accept: text/html, application/xhtml+xml, image/jxr, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US
Authorization: Basic YW3Rt2aW46dG4V3zdD5EyMz6Q=
Cache-Control: no-cache
Connection: Keep-Alive
Content-Length: 3521
Content-Type: application/x-www-form-urlencoded
Cookie: JSESSIONID=urVBPpjD3QrP6KhkqCK4r8KSAuvKFSVPdp-UXyz-FYSz4W0cQmV9sh!4524586920
Host: localhost:7001
Referer: //edited
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
</code>
Below is the response headers
<code>
Response Headers
Cache-Control: private, no-cache, no-store
Content-Disposition: attachment; filename="Closed DSP01 CRD0037_2019-12-26_133924.csv"
Content-Encoding: gzip
Content-Type: text/csv; charset=UTF-8
Date: Thu, 26 Dec 2019 08:09:23 GMT
Expires: 0
Pragma: no-cache
Transfer-Encoding: chunked
</code>
particular code where compression is done
<code>
if (canUseGzip) {
response.setHeader("Content-Encoding", "gzip");
GZIPOutputStream out = new GZIPOutputStream(response.getOutputStream());
pw = new OutputStreamWriter(out, "UTF-8");
} else {
pw = response.getWriter();
}
</code>
I tried different possibilities and when I tried to explicitly set content-length header ,say,
response.setHeader("Content-Length", String.valueOf(1024));
the file got downloaded successfully in IE. When I googled, I found transfer-encoding and content-length are mutually exclusive and former is already on the response. I don't know why adding content-length worked here and it was required only on the Spring migrated code. File gets downloaded successfully on older struts framework without mentioning the content-length header.
Is there anything specific I am missing here? Is there any other permanent solution as well?
Also how to correctly set the content length? I randomly tried with 1024 and it may fail for some other data.
Any help is appreciated

error 503 with gwt project

I'm trying to run a GWT project into DevMode, After running google compilation and lanching the devMode i'm getting a url, so when running into mozila, i'm getting the 503 error.
my console is displaying the following :
[ERROR] 503 - GET /travelApp?gwt.codesvr=127.0.0.1:49822 (127.0.0.1) 1296 bytes
Request headers
Host: localhost:8888
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Response headers
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 1296
i don't understand the problem, can you help me with that ?

What you see is the response from the webserver. The Error-Code is 503 - Service Unavailable (https://en.wikipedia.org/wiki/List_of_HTTP_status_codes).
Most likey, your application failed to start.
Do you have any logs? There might be any usefull stacktraces.
Do you use the build-in Jetty? I found out, that it's sometimes hard to get log entries from it. Maybe you can try to deploy the application to tomcat to get a more helpful errorlog.

How can I talk to nginx using plain HTTP/1.1 with pure Java sockets?

I connect a nginx http service by socket,i use java Language：
url：api.weibo.com/2/users/show.json
GET /2/users/show.json HTTP/1.1
Host: api.weibo.com
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.99 Safari/537.36
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6
Cookie: PHPSESSID=uc67dtcb5r3orchgv0dgdd0f57; think_template=default
but it return：
HTTP/1.1 400 Bad Request
Server: Weibo
Date: Sat, 24 Jan 2015 10:07:33 GMT
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Api-Server-IP: 10.75.0.174
Vary: Accept-Encoding
60
{"error":"source paramter(appkey) is missing","error_code":10006,"request":"/2/users/show.json"}
0
i don't know what is the '60' and '0'
if i use HTTP/1.0 instand of HTTP/1.1,it return:
HTTP/1.1 400 Bad Request
Server: Weibo
Date: Sat, 24 Jan 2015 10:22:09 GMT
Content-Type: application/json;charset=UTF-8
Connection: close
Api-Server-IP: 10.75.5.92
Vary: Accept-Encoding
{"error":"source paramter(appkey) is missing","error_code":10006,"request":"/2/users/show.json"}
if i use socket connect iis or apache,all ok to use HTTP/1.1
Anybody can tell me why,and how to Solve?

The webservice returns the content in chunks, by first sending the length of the next chunk. It is using Chunked Transfer Encoding.
You are saying you can speak HTTP/1.1 with GET /2/users/show.json HTTP/1.1 and
All HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer-coding....
You could use something like the Apache HttpClient or some other Java HTTP client library to avoid implementing HTTP on your own.

GAE Java SDK: appengine-web.xml "<static-file><include..." priority

I'm using the Google App Engine Java SDK 1.7.2 to serve some static files. When combining multiple <include... elements under <static-files> in appengine-web.xml, I am unsure which rules will take precedence.
For example, I have the following:
<static-files>
<include path="/**.swf" expiration="365d"></include>
<include path="/**.jpg" expiration="365d"></include>
<include path="/**"></include>
<exclude path="/**.php"></exclude>
</static-files>
I believe this specifies that everything should be included in static storage, except .php files, and that .swf and .jpg files should have "cache-control" and "expires" http headers set 365 days in the future.
However, when using the Live HTTP Headers tool for Firefox, I could not see the expected headers for static files with the long expiration:
http://localhost:8888/swf/Logo.20120927.swf
GET /swf/Logo.20120927.swf HTTP/1.1
Host: localhost:8888
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20100101 Firefox/15.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Referer: http://localhost:8888/
If-Modified-Since: Thu, 27 Sep 2012 15:49:03 GMT
Cache-Control: max-age=0
HTTP/1.1 304 Not Modified
Server: Jetty(6.1.x)
----------------------------------------------------------
http://localhost:8888/images/logo-and-buttons.20120927.jpg
GET /images/logo-and-buttons.20120927.jpg HTTP/1.1
Host: localhost:8888
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20100101 Firefox/15.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Referer: http://localhost:8888/
If-Modified-Since: Thu, 27 Sep 2012 15:49:03 GMT
Cache-Control: max-age=0
HTTP/1.1 304 Not Modified
Server: Jetty(6.1.x)
My question is, if this is not operating as expected, then how do I configure my <static-files> element to achieve the desired effect?
Cheers,
Jeff.

I have answered my own question: The reason I was getting "cache-control: max-age" values of 0, and no "expires" values in my HTTP headers, was because I was just reloading the page in Firefox. Upon starting a new Private Browsing session (resetting the cache in the process), and loading the page for the first time, I received the expected headers.

Need to submit forms twice to be processed?

Recently I notice that all action for submitting forms need to be executed twice to actually submit the values. Before this worked fine when I hard coded the resulting action path from my backing beans, but since I started to resolve all action path via the faces-config strange things has started to happen. One thing is that I need to press a submit button twice to fire the action, the browser fires the POST. I can see in firebug that two POST is fired and only the last one is processed by Glassfish.
Don know if this is side effect of the problem I experience. But many times when I do a forward the page losses CSS classes and things start to look ugly and some components (Richfaces - datatable) start to render badly. Actually I have to do redirect most of the time for things to render properly.
What can be the reason that I need to do two POST/submit before the Glassfish server will process the request ?
Why do I constantly need to redirect to make components (Richfaces) to render correctly ?
I use:
Glassfish 3.1
NetBeans 7.0.1
Richfaces 4.0-final
Sample of my Faces-config;
<navigation-rule>
<from-view-id>*</from-view-id>
<navigation-case>
<from-outcome>CreateActivity</from-outcome>
<to-view-id>/app_user/activity/Create.xhtml</to-view-id>
<redirect />
</navigation-case>
</navigation-rule>
<navigation-rule>
<from-view-id>*</from-view-id>
<navigation-case>
<from-outcome>CreateActivityDetail</from-outcome>
<to-view-id>/app_user/activity/UpdateDetail.xhtml</to-view-id>
</navigation-case>
</navigation-rule>
Firebug log --
First POST (doesn't work when submitted)
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Faces-Request: partial/ajax
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://localhost:8080/humis/faces/app_user/activity/List.xhtml
Content-Length: 430
Cookie: JSESSIONID=cd70a069ad528b3923bd52f12b1c
JSESSIONID=cbe0c977cf1c550f2a57cb4b334f;
treeForm_tree-hi=treeForm:tree:resources:jmsResources:jmsDestinationResources
Pragma: no-cache
Cache-Control: no-cache
First Response
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.1 Java/Sun Microsystems Inc./1.6), JSF/2.0
Server: GlassFish Server Open Source Edition 3.1.1
Cache-Control: no-cache
Content-Type: text/xml;charset=ISO-8859-1
Content-Length: 667
Date: Thu, 18 Aug 2011 13:30:22 GMT
Second POST (the one that works)
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Faces-Request: partial/ajax
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://localhost:8080/humis/faces/app_user/activity/List.xhtml
Content-Length: 494
Cookie: JSESSIONID=cd70a069ad528b3923bd52f12b1c;
JSESSIONID=cbe0c977cf1c550f2a57cb4b334f;
treeForm_tree-hi=treeForm:tree:resources:jmsResources:jmsDestinationResources
Pragma: no-cache
Cache-Control: no-cache
Second Response
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.1 Java/Sun Microsystems Inc./1.6), JSF/2.0
Server: GlassFish Server Open Source Edition 3.1.1
Cache-Control: no-cache
Content-Type: text/xml;charset=UTF-8
Content-Length: 145
Date: Thu, 18 Aug 2011 13:30:44 GMT

It sounds like that you've mapped the FacesServlet on multiple URL-patterns and that in some way all the autogenerated URLs to CSS and JS resources become invalid. Doing some basic debugging and investigation of the <link> and <script> URLs in the JSF-generated HTML source and the HTTP traffic with for example Firebug should give a lot of insights as to what exactly broke. You should have seen 404's for those CSS/JS resources.
As this trivial debugging information is missing in your question, I can't answer anything else than suggesting to trying to explicitly map the FacesServlet on a single URL pattern, e.g. *.xhtml.