Forum Discussion
hooleylist
Sep 11, 2007Cirrostratus
It looks like the client is making multiple requests before getting back the initial response containing the set-cookie header. This could either be pipelined on the same TCP connection or separate TCP connections.
Also, from this snippet of the log output, it seems that the client isn't always presenting the cookie even after it's been set:
: client 10.2.47.82 with cookie 44244085 -> /Static/images/common/icons/r.gif, count: 15
: client 10.2.47.82 with no cookie over limit, redirected -> /Static/images/common/c/divider.gif, count: 15
You could get a bit more detail by logging the client TCP port [TCP::client_port] and the number of requests a client has made on the same TCP connection [HTTP::request_num]. You might also try using an interception proxy or browser plugin to record when the cookies are received and when they are sent.
Are the requests going through a proxy server, or is this truly one client making requests?
If the client is making multiple requests over the same TCP connection, you could not increment the counter and send back the same ClientID. This might work to ignore subsequent requests on the same TCP connection:
if {[HTTP::cookie exists "ClientID"] or [HTTP::request_num] > 1 } {
If the client is opening concurrent TCP connections, I'm not sure how best to handle it. One option might be to use the session table to track the requests per client IP. This would add memory overhead compared with using cookies though--and would be specific to the IP address as opposed to the browser.
Anyone else have ideas on how best to handle this?
Aaron