You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Sven Köhler <sk...@upb.de> on 2003/11/12 01:55:23 UTC

Cookies, Chunked-Post & Threads

Hi,

i'm working on a so called ProxyServlet which uses the Information 
provided by the ServletContainer to deliver the Requests to another 
Web-Server.
At present, i'm using the HttpMethod-Objects (GetMethod, PutMethod, ...) 
and HttpClient.execute() to deliver the Requests to the other Web-Server.

I hope you can provide me with some sollutions to the following Problems:

- I like to maintain one "Cookie-Container" for each Session (Session = 
Session-Object offered by the Servlet-Container)
- I like my Servlet to be Thread-safe and be abled to deliver many 
(unlimited) requests at a time
- I tried to avoid the Content-Length Header in POST requests by using 
Chunked Transfer-Encoding, but the Apache-Server i'm using for testing 
seems to deny chunked POST-requests.

Well, how's cookie-management done in Commons-HttpClient? Does each 
HttpClient-Object maintain it's own "Cookie-Container"? 
HttpClient.execute() doesn't seem to be thread-safe.
I like chunked Transfer-Encoding since is more like a stream and not 
like that huge block of data that's usually used (content-length header 
etc.) Are chunked POST-Requests not allowed? Well, i'm setting the 
content-length header right now if it is provided to the servlet. So 
that's a big proble, but i'm just curious.

Thx
   Sven




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


Re: Cookies, Chunked-Post & Threads

Posted by Sven Köhler <sk...@upb.de>.
> browsers make requests in parallel for *one* user!
> Meaning that all the cookies returned end up in the
> same cookie store, as they do here.
> A proxy servlet will make requests for different users
> (browsers) and therefore has to maintain a different
> state for each user. That state is typically associated
> with the session between the browser and servlet.

I maintain a HttpState-Object for each Session the Servlet sees.

> It's either that, or different state objects for each
> session. But you can't just throw all cookies returned
> for all users into a single state and expect the HTTP
> client to figure out which cookie belongs to which
> user.

Sorry, it seems we missunderstood each other. I never wanted to put all 
in one HttpState-Object. My intention was to maintain one "CookieBox" 
per Session and that's what i do with the HttpState-Objects at the moment.

Everything works fine now.
Thanks for your help.

Sven


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


Re: Cookies, Chunked-Post & Threads

Posted by Roland Weber <RO...@de.ibm.com>.
Hello Sven,

browsers make requests in parallel for *one* user!
Meaning that all the cookies returned end up in the
same cookie store, as they do here.
A proxy servlet will make requests for different users
(browsers) and therefore has to maintain a different
state for each user. That state is typically associated
with the session between the browser and servlet.

I have rewritten our own proxy servlet to optionally use
the HTTP Client instead of the HttpURLConnection,
and I didn't encounter problems with parallel requests
by now. Which could also indicate that I didn't have
enough time to test it thoroughly yet :-)
Anyway, I handle "cookie" and "set-cookie" headers
manually and use a single state object that does
never store any cookies. And when manually handling
the cookies, I use a "CookieBox" class that gets
instantiated once for each session.
It's either that, or different state objects for each
session. But you can't just throw all cookies returned
for all users into a single state and expect the HTTP
client to figure out which cookie belongs to which
user.

regards,
  Roland

 




Sven Köhler <sk...@upb.de>
12.11.2003 15:40
Please respond to "Commons HttpClient Project"
 
        To:     Commons HttpClient Project 
<co...@jakarta.apache.org>
        cc: 
        Subject:        Re: Cookies, Chunked-Post & Threads


> unless you have taken special precautions, the state object
> is used to store cookies. Using the same state from different
> threads can mix up the cookies from different clients pretty
> badly.
> Once you have the cookie problem solved, there is no issue
> with using the same state object. I dimly remember seeing
> some synchronized statements in there. Anyway, except for
> storing cookies, it is accessed read-only.

Well, it's a that odd application of the HttpState-Object since every 
browser makes multiple requests to a server in parrallel. So this would 
be a feature i would request.

Well, most methods of HttpState seem to be synchronized, but as i 
already mentioned, it's pretty easy to easy to solve any "bad mix-up".

What i don't want is to serialize (meaning executing one after another) 
the HTTP-Requests. I want them to execute in parralel.


---------------------------------------------------------------------
To unsubscribe, e-mail: 
commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: 
commons-httpclient-dev-help@jakarta.apache.org



Re: Cookies, Chunked-Post & Threads

Posted by Sven Köhler <sk...@upb.de>.
> unless you have taken special precautions, the state object
> is used to store cookies. Using the same state from different
> threads can mix up the cookies from different clients pretty
> badly.
> Once you have the cookie problem solved, there is no issue
> with using the same state object. I dimly remember seeing
> some synchronized statements in there. Anyway, except for
> storing cookies, it is accessed read-only.

Well, it's a that odd application of the HttpState-Object since every 
browser makes multiple requests to a server in parrallel. So this would 
be a feature i would request.

Well, most methods of HttpState seem to be synchronized, but as i 
already mentioned, it's pretty easy to easy to solve any "bad mix-up".

What i don't want is to serialize (meaning executing one after another) 
the HTTP-Requests. I want them to execute in parralel.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


Re: Cookies, Chunked-Post & Threads

Posted by Roland Weber <RO...@de.ibm.com>.
Hello Sven,

unless you have taken special precautions, the state object
is used to store cookies. Using the same state from different
threads can mix up the cookies from different clients pretty
badly.
Once you have the cookie problem solved, there is no issue
with using the same state object. I dimly remember seeing
some synchronized statements in there. Anyway, except for
storing cookies, it is accessed read-only.

regards,
  Roland







Sven Köhler <sk...@upb.de>
12.11.2003 15:02
Please respond to "Commons HttpClient Project"
 
        To:     Commons HttpClient Project 
<co...@jakarta.apache.org>
        cc: 
        Subject:        Re: Cookies, Chunked-Post & Threads


> HttpClient.executeMethod
>    (HostConfiguration, HttpMethod, HttpState)
> 
> If you have used the same client from different
> threads without specifying different states, that
> might be a problem.

Well, i use this method now from different thread with different 
HttpStates. I'd like to use even one HttpState-Object from different 
threads! Is that possible. I'm doing that right now, but i'm not sure if 
  the HttpClient-APIs cares about that case.

If not, that would be very easy:

synchronized (state)
{
   //get cookie headers
}

//execute HTTP-request

synchronized (state)
{
   //put cookie header
}



---------------------------------------------------------------------
To unsubscribe, e-mail: 
commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: 
commons-httpclient-dev-help@jakarta.apache.org



Re: Cookies, Chunked-Post & Threads

Posted by Sven Köhler <sk...@upb.de>.
> HttpClient.executeMethod
>    (HostConfiguration, HttpMethod, HttpState)
> 
> If you have used the same client from different
> threads without specifying different states, that
> might be a problem.

Well, i use this method now from different thread with different 
HttpStates. I'd like to use even one HttpState-Object from different 
threads! Is that possible. I'm doing that right now, but i'm not sure if 
  the HttpClient-APIs cares about that case.

If not, that would be very easy:

synchronized (state)
{
   //get cookie headers
}

//execute HTTP-request

synchronized (state)
{
   //put cookie header
}



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


Re: Cookies, Chunked-Post & Threads

Posted by Roland Weber <RO...@de.ibm.com>.
Hello Sven

you don't specify the HttpState for a connection.
You specify it for each method execution:

HttpClient.executeMethod
   (HostConfiguration, HttpMethod, HttpState)

If you have used the same client from different
threads without specifying different states, that
might be a problem.

regards,
  Roland






Sven Köhler <sk...@upb.de>
12.11.2003 14:27
Please respond to "Commons HttpClient Project"
 
        To:     Commons HttpClient Project 
<co...@jakarta.apache.org>
        cc: 
        Subject:        Re: Cookies, Chunked-Post & Threads


> 1. Cookie Container:
> Let every session use it's own HttpState object. That's where
> HTTP Client stores it's cookies. The only problem is that it's
> not serializable, so it won't work with persistent sessions.

That's OK, but how do i say which HttpState to use for which connection?

> 2. Thread Safety:
> HTTP Client is thread safe as long as you use a thread safe
> connection manager.

Perhaps that's a bug or just intended behaviour, but multiple 
HttpClient-Object used from different threads using one 
MultiThreadHttpConnectionManager doesn't seems to work properly.



---------------------------------------------------------------------
To unsubscribe, e-mail: 
commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: 
commons-httpclient-dev-help@jakarta.apache.org



Re: Cookies, Chunked-Post & Threads

Posted by Sven Köhler <sk...@upb.de>.
> 1. Cookie Container:
> Let every session use it's own HttpState object. That's where
> HTTP Client stores it's cookies. The only problem is that it's
> not serializable, so it won't work with persistent sessions.

That's OK, but how do i say which HttpState to use for which connection?

> 2. Thread Safety:
> HTTP Client is thread safe as long as you use a thread safe
> connection manager.

Perhaps that's a bug or just intended behaviour, but multiple 
HttpClient-Object used from different threads using one 
MultiThreadHttpConnectionManager doesn't seems to work properly.



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


Re: Cookies, Chunked-Post & Threads

Posted by Roland Weber <RO...@de.ibm.com>.
Hello Sven,

1. Cookie Container:
Let every session use it's own HttpState object. That's where
HTTP Client stores it's cookies. The only problem is that it's
not serializable, so it won't work with persistent sessions.

2. Thread Safety:
HTTP Client is thread safe as long as you use a thread safe
connection manager.

3. Unlimited Requests:
Adjust the parameters of the MultiThreadedConnectionManager
to change the maximum number of simultaneous requests. Your
servlet container most likely has some load limitation policy, so
you don't have to allow much more connections than there are
threads to execute servlets.

(no clue about content length in POST requests)

regards,
  Roland






Sven Köhler <sk...@upb.de>
12.11.2003 01:55
Please respond to "Commons HttpClient Project"
 
        To:     Commons HttpClient Project 
<co...@jakarta.apache.org>
        cc: 
        Subject:        Cookies, Chunked-Post & Threads


Hi,

i'm working on a so called ProxyServlet which uses the Information 
provided by the ServletContainer to deliver the Requests to another 
Web-Server.
At present, i'm using the HttpMethod-Objects (GetMethod, PutMethod, ...) 
and HttpClient.execute() to deliver the Requests to the other Web-Server.

I hope you can provide me with some sollutions to the following Problems:

- I like to maintain one "Cookie-Container" for each Session (Session = 
Session-Object offered by the Servlet-Container)
- I like my Servlet to be Thread-safe and be abled to deliver many 
(unlimited) requests at a time
- I tried to avoid the Content-Length Header in POST requests by using 
Chunked Transfer-Encoding, but the Apache-Server i'm using for testing 
seems to deny chunked POST-requests.

Well, how's cookie-management done in Commons-HttpClient? Does each 
HttpClient-Object maintain it's own "Cookie-Container"? 
HttpClient.execute() doesn't seem to be thread-safe.
I like chunked Transfer-Encoding since is more like a stream and not 
like that huge block of data that's usually used (content-length header 
etc.) Are chunked POST-Requests not allowed? Well, i'm setting the 
content-length header right now if it is provided to the servlet. So 
that's a big proble, but i'm just curious.

Thx
   Sven




---------------------------------------------------------------------
To unsubscribe, e-mail: 
commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: 
commons-httpclient-dev-help@jakarta.apache.org



Re: Cookies, Chunked-Post & Threads

Posted by Andreas Probst <an...@gmx.net>.
Hi Sven, 

Regarding the thread safeness, I suggest try using 
MultiThreadedHttpConnectionManager. Instance it and put into 
HttpClient's constructor.

Regards.

Andreas

On 12 Nov 2003 at 1:55, Sven Köhler wrote:

> Hi,
> 
> i'm working on a so called ProxyServlet which uses the Information 
> provided by the ServletContainer to deliver the Requests to another 
> Web-Server.
> At present, i'm using the HttpMethod-Objects (GetMethod, PutMethod, ...) 
> and HttpClient.execute() to deliver the Requests to the other Web-Server.
> 
> I hope you can provide me with some sollutions to the following Problems:
> 
> - I like to maintain one "Cookie-Container" for each Session (Session = 
> Session-Object offered by the Servlet-Container)
> - I like my Servlet to be Thread-safe and be abled to deliver many 
> (unlimited) requests at a time
> - I tried to avoid the Content-Length Header in POST requests by using 
> Chunked Transfer-Encoding, but the Apache-Server i'm using for testing 
> seems to deny chunked POST-requests.
> 
> Well, how's cookie-management done in Commons-HttpClient? Does each 
> HttpClient-Object maintain it's own "Cookie-Container"? 
> HttpClient.execute() doesn't seem to be thread-safe.
> I like chunked Transfer-Encoding since is more like a stream and not 
> like that huge block of data that's usually used (content-length header 
> etc.) Are chunked POST-Requests not allowed? Well, i'm setting the 
> content-length header right now if it is provided to the servlet. So 
> that's a big proble, but i'm just curious.
> 
> Thx
>    Sven
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org