JsonRpcHttpClient when executing multiple API calls, it does not handle the session cookies set by the server.

[GoogleCodeExporter]

The com.googlecode.jsonrpc4j.spring.JsonServiceExporter class is used to  
export a POJO as JSONRPC service. All the client requests goes through the 
DispatcherServlet. One API in the POJO class is createSession, which validates 
the user credentials and create a session and stores it in the spring's 
SecurityContextHolder.

The session is handled with a cookie JSESSIONID.

What steps will reproduce the problem?
1. The class JsonRpcHttpClient does not store and forward the cookies set by 
the server.
2. There is a JSONRPC API for createSession and each subsequent call is 
identified by the HTTP cookie.
3. Since this class does not store and forward the session, the user has to 
explicitly set the cookie in the header.

What is the expected output? What do you see instead?
The class JsonRpcHttpClient should handle the cookies set by the server.

What version of the product are you using? On what operating system?
0.25-SNAPSHOT on Windows XP.

Please provide any additional information below.
I have a code fix for this issue, I have modified the method invoke(...) in the 
class JsonRpcHttpClient, which will look for the cookies in the http response 
and send them in the next http request.

Original issue reported on code.google.com by chandu.d...@gmail.com on 14 Aug 2012 at 7:19

[GoogleCodeExporter]

Please let me know how I can get my code change reviewed, so that I commit the 
fix for this issue.

Original comment by chandu.d...@gmail.com on 14 Aug 2012 at 7:24

[GoogleCodeExporter]

I'm going to abstract away the HTTP implementation for the client.  It'll make 
it easier to do things like this.  With that said, cookies aren't part of the 
JSON-RPC spec, so it's not a good idea to accept a patch to the existing code 
that merely remembers previous cookies.  That said, i haven't seen your patch - 
so i don't know what you've done exactly :)

Original comment by br...@chee.rs on 20 Aug 2012 at 4:11

[GoogleCodeExporter]

I agree with abstracting the HTTP implementation from the client. 

I have added the following lines of code in the JsonRpcHttpClient.invoke(...) 
method at line # 128, before the return statement.

        String cookie = con.getHeaderField("Set-Cookie");
        if (cookie != null && cookie.contains("JSESSIONID")) {
           int start = cookie.indexOf("JSESSIONID");
           int end = cookie.indexOf(';', start);
           if (end < 0) 
              end = cookie.length();
           cookie = cookie.substring(start, end);
           headers.put("Cookie", cookie);
        }

This just stores the JESSIONID cookie, just to maintain the HTTP session.

I am not a member of this project, so I will not be able to checkout the 
project or file in the read/write mode.

Original comment by chandu.d...@gmail.com on 21 Aug 2012 at 3:16

[GoogleCodeExporter]

You can check it out in read only mode, edit it, and created a patch.

With that said, I still wont accept a patch with the code you've pasted above.

1) HTTP cookies aren't part of the JSON-RPC spec
2) It's not safe to assume that the cookie's name is "JSESSIONID" every time

When we've abstracted the HTTP implementation we can talk about supporting this 
functionality.

Original comment by brian.di...@gmail.com on 27 Aug 2012 at 1:03

[GoogleCodeExporter]

Marking this invalid - when the new HTTP abstraction is in place you can do 
whatever configuration is needed to make this happen.  Cookies are not part of 
the JSON-RPC spec.

Original comment by brian.di...@gmail.com on 3 Oct 2012 at 11:25

• Changed state: Invalid