Develop Reference

Session gets lost when you move from one page to other

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

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.

response.sendRedirect() gives HTTP ERROR: 400 BAD_REQUEST only in IE

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.

WRITE_ERROR_TO_CLIENT Error in apache

I am getting the below error. Env is Apache and WEblogic.
Write to the client failed: calling URL::close at line 847 of ap_proxy.cpp
Exception type [WRITE_ERROR_TO_CLIENT] raised at line 848 of ap_proxy.cpp
request [/mywebservice?WSDL] did NOT process successfully

AFroz: I am getting the same error but in Weblogic10.3 and IIS plugin. Below are my finding and resolutions
Post my application was sending to IIS server
POST <hostname/pagedetails> HTTP/1.0'
Accept: image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, /
Referer:
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729;.NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; .NET4.0C)
Content-Type: application/x-www-form-urlencoded
Host:
<b>Content-Length: 38579</b>
Proxy-Connection: Keep-Alive
Pragma: no-cache
Cookie: `SMSESSION=
`JSESSIONID=0JppPKFpLXk8HMynBLDbBJPltLL70GvQ8Cyl56hhnXbjT7JbrgmR!847042037
Error recived
HTTP/1.1 500 Internal Server Error
Server: Microsoft-IIS/5.0
Date: Mon, 09 Jan 2012 10:56:31 GMT
Set-Cookie: SMSESSION=85psVrPSuTRavlFjc8+YLNNKjH82me4KdX8t57d3RMn/6DDYk37CarBHHbT1Z0cCJTPSH48jAhgvrlLcFgNzwwLYoTkQRaKTZljCz4wCyiuj5gsx8yPBZL4h/HkaCVZMNQam5+En3UO2G8sQJ33DviYiMiX5i/azf8m06s2MyTCk6ngT/5u5rMm2SpWBlDfW/JLUEkcRD4RjQCeMP4P0Vzt8mw3oD0O/owscfaUx/nfWCAzDFEiIPkPqkEo2pUzHbfKHoQzm3AnI9cfGMjXJ8yns7dmpOOuGI0uMQzWgsv9S1+zr2VBewY7qnAyVX1MhUP203HlHjUO9rtqnDmOIqbHLMR3PRnY60VL8qpnYcrdkpLHEQEvZLxbHFoh+BL3xVqaRZnz13Cs11BsgXWztnpMYfpl3W2qLBGJ8Cd1zuN/zzJxPY0NYdz0iSd5gOtvk+KcQvxNb1a/1VXIj60H5bsjVJIK9k2lqTN3B3qEdDZ4YpG/fKgFL4a2eLtTcUYatQhZxDGQvjWY+Yla+qu7tt0JihzIOGkqgJINPEBQLfC52ADD1tvzIW4LuFwVaPp4lojGj5ykfX1v63Xo5WbhBGoH3wo2vQlUy1eKDec3SVqygk5d1y7V178oDJfbxwMRNJnPbaVRyIVUmCcEiV3IE+MrJ+Nwy+NUD4k6CGVQ+3us0G7E5AU4tiTBPPPJuKduJfH4IkiLUx6GL+ug5JIrTQVlrQQtV4Y7bdgJ2UavRbuEnUPqTr5zNJKDElr1oXtp9emah2e7goL55Gjb/p5mFi0UvmtMOmN0ffgjyYWRVqq8p5hJ0HWi6jxQinfCrQvBPAltWPeWWT9vX/apTBVdBrbMcOIFwbBcdVeTYe6Ubb+T+uxXbEthleU25bAppP60pz5wsCh/jLLf/gXk72hg55yzDG8arfZavwOLUtFEes666tvf+L65IX6lYvjNcKei4bXz7PRHzg0tvQBGM9ymFdZA0nJ3X0IzeLzukuWLd6Wo=; path=/; domain=
Content-Type: text/html
ISAPI plug-in Error MessageMessage from the ISAPI plugin:
Internal Server failure, ISAPI plugin. Cannot continue.
Build date/time: Jan 31 2003
Change Number: 235118
When I have removed the below line from the post it gave us the correct response.
Content-Length: 38579
The server was able to process
Issue:
The error is due to the browser not sending the correct character count to the IIS server.
Actual Size of the request header is 38597
Resolution:
As in Javascript we can't remove the Content-Length from the header
We need to do the changes in IIS side
ie
In InetMgr you need to Server Node -> Application Request Routing Cache -> Server Proxy Settings and increase Buffer Setting.
Other Uri :
http://www.iis.net/download/ApplicationRequestRouting
http://forums.iis.net/t/1174461.aspx
Tools used to find the post :
tcp_reflector
www.vulcanware.com/java_tcp_reflector/index.html

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.