Return Receipt
                                                                           
   Your       [Pound Mailing List] poundctl bad flag                       
   document:                                                               
                                                                           
   was        Neil R Taylor/UK/IBM                                         
   received                                                                
   by:                                                                     
                                                                           
   at:        06/02/2007 15:30:54

On Tue, 2007-02-06 at 13:10 +0000, Anthony Underwood wrote:[...]

It seems to be a bug - we'll fix it in the next release. Thanks for
pointing this out.[...]

On Tue, 2007-02-06 at 13:55 +0100, Francisco Ruiz wrote:[...]

These really are two separate issues.

1. Keeping sessions for a dead back-end: why would you want to do that?
Once a server is dead, in all likelihood the sessions are gone as well,
so there is no advantage to it.

2. Showing a "special" page: you have two possibilities: either use the
custom error pages to return it in Pound, or have your application
redirect to a special page if the request contains an invalid session
key (which is good practise anyway).[...]

Robert Segall escribió:

  On Tue, 2007-02-06 at 13:55 +0100, Francisco Ruiz wrote:
  
  
    Hello,

I'm new with Pound, so I'm looking for some clue for a concrete problem.

We are using the session control based on cookies, and whenever a 
backend dies all the sessions assigned to it are removed, so if the 
client tries to access again the site it is redirected to any of the 
alive backends inmediatly. Since it has his session open on the dead 
backend the user should close it browser and open it again in order a 
new session cookie to be created, but pound just redirect it and the 
application does not work correctly.

What I'm looking for is for something like a "Zombie" directive in the 
Session section.  If this directive is defined, the sessions should not 
be removed when the backend dies, instead of this pound should send a 
redirect to a new page (defined in the directive).  The zombie sessions 
should be removed when their TTL is reached.


For example:
 
  Session
    Type COOKIE
    TTL 7200
    ID "ASPSESSIONID.*"
    Zombie "http://server/error.html"
  End

or

  Session
    Type COOKIE
    TTL 7200
    ID "ASPSESSIONID.*"
    Zombie "http://server/relogin.html"
  End


Thanks in advance. Regards

Francisco Ruiz
    
  
  
These really are two separate issues.

1. Keeping sessions for a dead back-end: why would you want to do that?
Once a server is dead, in all likelihood the sessions are gone as well,
so there is no advantage to it.
  

That's true, but the client's doesn't know that the backend is gone and
try to access again with the same session cookie, pound has forgotten
the session associated to this cookie and simply create a new session
assigned to a new backend. When the application receive the request it
doesn't know the sessions and fails to give a correct answer.

  
2. Showing a "special" page: you have two possibilities: either use the
custom error pages to return it in Pound, or have your application
redirect to a special page if the request contains an invalid session
key (which is good practise anyway).
  

Your are right, my application could redirect to a special page if the
request contains an invalid session, but it was not done in the
original design and now is pretty hard to change all, so I was looking
for this kind of support inside Pound as I thought it could be useful
in many cases, no just for me.

Regards,

Francisco Ruiz

Francisco Ruiz wrote:
[...]

Hello,
[...]

Hm, why don't you improve the session handling in your application? If 
the user visits your website with an invalid session cookie, he should 
be redirected to an authentication page to log in again. The lack of 
validating session cookies _can_ be fixed by the used load balancer, but 
this only a workaround in my eyes :-)

Regards,

Falk

Hello Falk,


Falk Brockerhoff - smartTERRA GmbH escribió:
[...]
Sure, but that's not easy when you have serveral applications that 
does'nt make it right, and it's not easy to change them cleanly.  So 
this feature could be very useful in this situations.

Regards,

Francisco

There's no real way for Pound to know if an expired session is expired, or if
it's a new session.  For that matter, you will still have problems if you
reboot the application server, because the application server will clear the
sessions out of memory, and you'll have stale cookies around.  Pound has no way
to check that.  And to add to that, sometimes URL variables are used to pass
the session key as well, in a manner Pound won't know.  (J2EE uses JSESSIONID,
coldfusion uses CFID/CFTOKEN, ASP uses sessionID I think)  It's possible a
session ID could be passed via URL variables and Pound wouldn't know.

In our applications we check for such things in our Application.cfm
(coldfusion's version of global.asa or similar constructs).  Every page is
checked for valid authentication and session information, and if it isn't
present it shows a login screen.  The check itself only adds about 5ms to each
page load.

Joseph Gooch
Sapphire Suite Product Manager
K12 Systems, Inc.
(866) 366-9540
[...]

We ran into this kind of problem (though on the end, not beginning).  
The carat '^' should bind your regex to the beginning of the URL,  
just like '$' binds to the end.

URL "^\/(photos|movies)\/.*"

Regards,
-Nathan / PBwiki

On Feb 11, 2007, at 4:27 PM, Mark Karp wrote:
[...]

Mark Karp napisał(a):[...]

Of course - you need to indicate "start of line" - a "^" character.
URL "^/(photos|movies)/.*" will catch only these URL's which begin
with the /photos or /movies. You may also use "$" character in order
to indicate "end of line", so: "^/$" will catch only pure "/" URL.

regards;
AdamLis;

Robert,

these might be silly questions , but which Libraries are you referring 
to?  And how do I find out?

Robert Segall wrote:[...]

On Fri, 2007-02-16 at 12:12 -0500, Albert wrote:[...]

It means the libraries Pound was linked against, such as OpenSSL. Each
system is a bit different; on Linux, *BSD and some Solaris versions you
could try:

	ldd pound

(where 'pound' is your binary) to see the list. If your system supports
no such command you can just look at the installed packages (usually
in /usr/lib). The really important ones are libssl, libcrypto and
optionally - if you use them - libpcre, libpcreposix and libtcmalloc (or
libhoard).[...]

Robert Klikics schrieb:
[...]

AFAIK no. But what's about using 'Type IP'? So you are independent of
the used application and the users are identified by their client ip
address.

Regards,

Falk

Falk Brockerhoff schrieb:[...]

Well, we (everybody at my company) are are using our own application the 
whole day with massive requests and have alle the same IP via NAT (~300 
people).
If I change to type 'IP' the load is extremely on high on exactly one 
machine - and thats always the one on which is serving us ...
[...]
Regards,
Robert

This basically means the connection was closed by the client before 
pound was able to send the info back.  Did you try running your test by 
calling pound, instead of backend?

"Connection timed out" message is caused by a timeout on the read by 
pound from client.  You can increase "Client" value in the pound.cfg

Dennis Jacobfeuerborn wrote:[...]

Albert wrote:[...]

I set that to 90 seconds already. The thing I don't understand here is what 
does kind of information does pound read from the client and why would that 
take so long? Shouldn't pound just receive the initial request and then 
spend most of its time writing the data it receives from the backend to the 
client?

Regards,
   Dennis

Dennis Jacobfeuerborn wrote:[...]
just connected to you and is not sending the request.

Albert wrote:[...][...][...]

These are not just clients "out there". I simply hit the reload button in 
the browser and while most of the time things are fine every minute or so I 
just get the "internal server error" message. As I already mentioned 
contacting the backend directly works fine so I don't see how it can be the 
clients fault if it works just fine once you take pound out of the loop?

Regards,
   Dennis

Part of the difficulty here is that you are also taking the server side DNS
systems out of the loop as well as pound.  This and other similar effects
can cause confusing diagnostics.

Tracing the client and server side is important here.  For instance, we have
observed some clients that are ill-behaved in terms of actually sending an
entire request.  Without the last byte some systems time out.  I don't say
that is your problem, but that is an example of a problem that can only
really be solved using traces.

On 2/28/07 2:06 PM, "Dennis Jacobfeuerborn"
<d.jacobfeuerborn(at)conversis.de>
wrote:
[...][...]

Ted Dunning wrote:[...]

If the client was ill-behaved and apache manages to to send a correct 
response shouldn't pound be able to accomplish this too? I'd be perfectly 
happy to apply patches to get better information for the debug log to hunt 
this down but I would need assistance for that as I'm not familiar with the 
pound codebase. A dump of the data received by the client so far (up until 
the "timeout") and maybe the state of some important variables to the log 
would probably make it easier to determine where exactly the problem lies.

Regards,
   Dennis

On 2/28/07 9:21 PM, "Dennis Jacobfeuerborn"
<d.jacobfeuerborn(at)conversis.de>
wrote:
[...]

Not necessarily.  And defect in DNS can cause problems due to the fact that
pound is doing something more complex than is done by a single server.
[...]

You don't need patches.  Just some network sniffing software.  Tcpdump will
do, ethereal will do.

Ted Dunning wrote:[...][...][...][...][...]

They help though. The logging isn't very verbose for example I added code 
that outputs the IP of the client in case of "copy server cont" and "copy 
chunk cont" errors which makes the cross-referencing with other 
logfiles/tools much easier.

 > Just some network sniffing software.  Tcpdump will[...]

How would I go about that and what tcpdump options would be required? I now 
have a dump here done with "tcpdump -n -nn -w tcpdump.log port 80 or port 
443" and thanks to the logging change I can limit the contents to the 
communication between pound and the client. But what should I look for in 
that dump?

Regards,
   Dennis