I am working on a WEB Application. The app creates and stores all the user information on the first page in a session. When I move to the third page the session gets lost. I tried debugging the application the session is stored until the second page but when i move to the third page ActionContext.getContext().getSession(); returns null. I have set the session timeout to be 60000, so this is not because of a timeout. I am running the application on a Tomcat server. This is what i get after using Live-HTTP headers on firefox.
Host: localhost:9080 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:31.0) Gecko/20100101 Firefox/31.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
Referer: http://localhost:9080/App/collect.jsp
Cookie: JSESSIONID=B9EB26ACAC0ACC7B5920B08BA8D2136D
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 51
HTTP/1.1 500 Internal Server Error
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=64E1A2ADED0B3C827BAFF49159075205;
Path=/App/; HttpOnly
Content-Type: text/html;charset=ISO-8859-1
Transfer-Encoding: chunked
Date: Tue, 09 Jun 2015 23:36:31 GMT Connection: close
Related
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
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.
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.
I'm using Google App Engine (Java) with Google Accounts for authentication.
I've created a servlet (processSignIn.jsp) that makes sure the account should be allowed in for reasons other than a valid Google account (invite approved, etc.). If the code evaluates correctly, it issues a "response.sendRedirect(url)" to send the user to the URL specified by the "url" parameter.
If a user clicks this type of link:
<a href="<%= userService.createLoginURL("../processSignIn.jsp?url=" +
request.getRequestURI()) %>">Sign in with a Google Account</a>
Then signs in with their Google account, everything works ok with Firefox or Chrome but not with IE 9. See the requests and responses below.
Note the difference between the two GET headers... FF does not contain the "../" but IE does. I would like to continue using relative paths so I don't have to do anything odd for local dev testing.
What could be the issue?
Firefox Request:
GET http://www.[mydomain].com/processSignIn.jsp?url=/main.jsp HTTP/1.1
Host: www.[mydomain].com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.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
Cookie: [my cookie data]
Firefox Response:
HTTP/1.1 302 Found
Content-Type: text/html
Location: http://www.[mydomain].com/main.jsp
X-AppEngine-Estimated-CPM-US-Dollars: $0.000138
X-AppEngine-Resource-Usage: ms=18 cpu_ms=0 api_cpu_ms=0
Date: Sun, 11 Dec 2011 02:58:06 GMT
Server: Google Frontend
Content-Length: 0
IE 9 Request:
GET http://www.[mydomain].com/../processSignIn.jsp?url=/main.jsp HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Pragma: no-cache
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Cookie: [my cookie data]
Accept-Encoding: gzip, deflate
Host: www.[mydomain].com
Connection: Keep-Alive
Cache-Control: no-cache
IE 9 Response:
HTTP/1.1 400 Bad Request
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html; charset=iso-8859-1
X-AppEngine-Estimated-CPM-US-Dollars: $0.001025
X-AppEngine-Resource-Usage: ms=13 cpu_ms=32 api_cpu_ms=0
Vary: Accept-Encoding
Date: Sun, 11 Dec 2011 03:00:23 GMT
Server: Google Frontend
Content-Length: 1292
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>Error 400 BAD_REQUEST</title>
</head>
<body>
<h2>HTTP ERROR: 400</h2>
<p>Problem accessing /../processSignIn.jsp. Reason:
<pre> BAD_REQUEST</pre></p>
<hr /><i><small>Powered by Jetty://</small></i>
That can only mean that the generated <a> element has an URL with /../ inside which made MSIE and Jetty to choke. Please note that your JSP/servlet code wasn't even hit. It was Jetty who blocked the request immediately due to bad URI.
To solve the bad URI, just don't use context-relative URLs with ../, but rather use domain-relative URLs. In your case that would be
<a href="<%= userService.createLoginURL(request.getContextPath()
+ "/processSignIn.jsp?url=" + request.getRequestURI()) %>">
By the way, I wonder what that userService.createLoginURL() is supposed to do. It seems to do nothing special at all.
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.