Re: stacked handlers return vals
Geoffrey Young wrote: > > > what is wrong with DONE? DONE immediatly closes the client > > connection > > > and starts the logging phase. if you have sent the content already > > > then there is nothing to worry about. the call to send_http_header > > > will pick up on the any status you set previously or use the default > > > HTTP_OK set at the start of the request. > > > > Isn't DONE ignored like OK and DECLINED? "Writing Apache Modules > > w. P.a.C." says: > > > > "..Each handler will be called in turn in the order in which it was > > declared. The exception to this rule is if one of the handlers in the > > series returns an error code (anything other than OK, DECLINED, or > > DONE)..." > > ok, I think that paragraph can be read a few ways. > > pretty much anything other than OK, DECLINED, or DONE is treated as an error > and starts the error processing cycle. even things like REDIRECT. that's > what I think the parenthetical was talking about. now, that aside, DONE has > special meaning to Apache, namely ending the request and moving to the > logging phase. Looks like I was wrong about it closing the connection, > though - I thought I had both read and tested that, but I can't see in the > code where Apache overrides the current keepalive settings and in my tests > the connection was left open. > > the current implementation in perl_call_handler has exceptions for != OK, > then further processing for SERVER_ERROR and DECLINED. DONE appears to fall > through, which would appear to make it behave the way I described. > > however, the real proof is in testing, which for me shows exactly what I > expected - DONE terminates the chain and returns 200. try it yourself :) > > --Geoff OK thanks for all the help. I read the eagle book properly the second time and found the description of DONE (so this thread is getting a little embarrasing!). I'm using chained handlers now with $r->pnotes to coordinate all handler responses (Along with Apache::Filter to pass data along the chain) e.g. if the first handler returnes DECLINED, the rest will also because of a flag set with pnotes. Someone else suggested pnotes earlier in the thread. thanks again.
RE: stacked handlers return vals
> > what is wrong with DONE? DONE immediatly closes the client > connection > > and starts the logging phase. if you have sent the content already > > then there is nothing to worry about. the call to send_http_header > > will pick up on the any status you set previously or use the default > > HTTP_OK set at the start of the request. > > Isn't DONE ignored like OK and DECLINED? "Writing Apache Modules > w. P.a.C." says: > > "..Each handler will be called in turn in the order in which it was > declared. The exception to this rule is if one of the handlers in the > series returns an error code (anything other than OK, DECLINED, or > DONE)..." ok, I think that paragraph can be read a few ways. pretty much anything other than OK, DECLINED, or DONE is treated as an error and starts the error processing cycle. even things like REDIRECT. that's what I think the parenthetical was talking about. now, that aside, DONE has special meaning to Apache, namely ending the request and moving to the logging phase. Looks like I was wrong about it closing the connection, though - I thought I had both read and tested that, but I can't see in the code where Apache overrides the current keepalive settings and in my tests the connection was left open. the current implementation in perl_call_handler has exceptions for != OK, then further processing for SERVER_ERROR and DECLINED. DONE appears to fall through, which would appear to make it behave the way I described. however, the real proof is in testing, which for me shows exactly what I expected - DONE terminates the chain and returns 200. try it yourself :) --Geoff
Re: stacked handlers return vals
* Mark Maunder <[EMAIL PROTECTED]> wrote: > Nikolaus Rath wrote: > >> * Mark Maunder <[EMAIL PROTECTED]> wrote: >> > Hi, >> > >> > If I'm using stacked handlers, what should I return if I dont want the >> > next handler in line to run because I've returned all required content >> > to the client? (the eagle book says anything other than OK, DECLINED >> > or DONE, but what's the appropriate return val that wont cause the >> > client to think an error occured?) >> >> 200 / HTTP_DOCUMENT_FOLLOWS? >> >>--Nikolaus > > Nope, tried it already. It just goes on to the next handler as if you > returned OK. In this case i would use a request note. Modify each handler to abort if the request note is set and set the request note instead of the return value. --Nikolaus
Re: stacked handlers return vals
* Geoffrey Young <[EMAIL PROTECTED]> wrote: If I'm using stacked handlers, what should I return if I >> > > dont want the next handler in line to run because I've returned >> > > all >> required content to the client? (the eagle book says >> > > anything other than >> OK, DECLINED or DONE, but what's the >> > > appropriate return val that wont cause the client to think an >> > > error occured?) >>> >>> 200 / HTTP_DOCUMENT_FOLLOWS? >>> >> >> Nope, tried it already. It just goes on to the next handler as if you >> returned OK. > > what is wrong with DONE? DONE immediatly closes the client connection > and starts the logging phase. if you have sent the content already > then there is nothing to worry about. the call to send_http_header > will pick up on the any status you set previously or use the default > HTTP_OK set at the start of the request. Isn't DONE ignored like OK and DECLINED? "Writing Apache Modules w. P.a.C." says: "..Each handler will be called in turn in the order in which it was declared. The exception to this rule is if one of the handlers in the series returns an error code (anything other than OK, DECLINED, or DONE)..." --Nikolaus
Re: stacked handlers return vals
Geoffrey Young wrote: > > -Original Message- > > From: Mark Maunder [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, October 21, 2001 1:49 PM > > To: Nikolaus Rath > > Cc: [EMAIL PROTECTED] > > Subject: Re: stacked handlers return vals > > > > > > Nikolaus Rath wrote: > > > > > * Mark Maunder <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > > > > > If I'm using stacked handlers, what should I return if I > > dont want the > > > > next handler in line to run because I've returned all > > required content > > > > to the client? (the eagle book says anything other than > > OK, DECLINED > > > > or DONE, but what's the appropriate return val that wont cause the > > > > client to think an error occured?) > > > > > > 200 / HTTP_DOCUMENT_FOLLOWS? > > > > > >--Nikolaus > > > > Nope, tried it already. It just goes on to the next handler as if you > > returned OK. > > what is wrong with DONE? DONE immediatly closes the client connection and > starts the logging phase. if you have sent the content already then there > is nothing to worry about. the call to send_http_header will pick up on the > any status you set previously or use the default HTTP_OK set at the start of > the request. > > no matter what status you return, it matters not once you've sent your > headers. DONE is there if you want to close the client connection, which > will prevent any other PerlHandler from getting to the client > > HTH > > --Geoff Thanks, I missed that.
RE: stacked handlers return vals
> -Original Message- > From: Mark Maunder [mailto:[EMAIL PROTECTED]] > Sent: Sunday, October 21, 2001 1:49 PM > To: Nikolaus Rath > Cc: [EMAIL PROTECTED] > Subject: Re: stacked handlers return vals > > > Nikolaus Rath wrote: > > > * Mark Maunder <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > If I'm using stacked handlers, what should I return if I > dont want the > > > next handler in line to run because I've returned all > required content > > > to the client? (the eagle book says anything other than > OK, DECLINED > > > or DONE, but what's the appropriate return val that wont cause the > > > client to think an error occured?) > > > > 200 / HTTP_DOCUMENT_FOLLOWS? > > > >--Nikolaus > > Nope, tried it already. It just goes on to the next handler as if you > returned OK. what is wrong with DONE? DONE immediatly closes the client connection and starts the logging phase. if you have sent the content already then there is nothing to worry about. the call to send_http_header will pick up on the any status you set previously or use the default HTTP_OK set at the start of the request. no matter what status you return, it matters not once you've sent your headers. DONE is there if you want to close the client connection, which will prevent any other PerlHandler from getting to the client HTH --Geoff
Re: stacked handlers return vals
Nikolaus Rath wrote: > * Mark Maunder <[EMAIL PROTECTED]> wrote: > > Hi, > > > > If I'm using stacked handlers, what should I return if I dont want the > > next handler in line to run because I've returned all required content > > to the client? (the eagle book says anything other than OK, DECLINED > > or DONE, but what's the appropriate return val that wont cause the > > client to think an error occured?) > > 200 / HTTP_DOCUMENT_FOLLOWS? > >--Nikolaus Nope, tried it already. It just goes on to the next handler as if you returned OK.
Re: stacked handlers return vals
* Mark Maunder <[EMAIL PROTECTED]> wrote: > Hi, > > If I'm using stacked handlers, what should I return if I dont want the > next handler in line to run because I've returned all required content > to the client? (the eagle book says anything other than OK, DECLINED > or DONE, but what's the appropriate return val that wont cause the > client to think an error occured?) 200 / HTTP_DOCUMENT_FOLLOWS? --Nikolaus
stacked handlers return vals
Hi, If I'm using stacked handlers, what should I return if I dont want the next handler in line to run because I've returned all required content to the client? (the eagle book says anything other than OK, DECLINED or DONE, but what's the appropriate return val that wont cause the client to think an error occured?) tnx!
