> -----Original Message-----
> From: will trillich [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 30, 2001 9:44 PM
> To: [EMAIL PROTECTED]
> Subject: PerlAccessHandler -- struggling and drowning
>
>
> Eeyore here, again, less happy than ever. S.O.S.
>
> okay. i try to use the Ticket*.pm modules from the book
> (chapter 6) verbatim and they work well for well-behaved
> browsers.
>
But of course they do!
> to widen the workability (i.e. to make it functional for
> badly-mannered browsers*) i'm trying some workarounds.
Straying from the eagle is never a good idea.
> this is a PerlAccessHandler, which should check for the existence
> of a cookie in the incoming headers, and if not there (or
> expired) it should redirect the browser to a login area that
> takes name/password pair, and if valid, would then return the
> browser to the original URL. to do that, as we issue the
> 'redirect to the login area' we set a cookie containing the URL
> to return to.
PerlAccessHandlers can only allow, deny or remain agnostic on access. They
can't redirect and they can't send output to the screen. The example in the
book gets around this by denying access, and then using the ErrorDocument
directive to redirect the client.
If you insist on using this handler to perform redirects, you'll have to
switch it to a PerlInitHandler. If you want to send content to the browser,
you need to do so in a PerlHandler.
I can't say as I've had any problems using
err_headers_out->add("Set-Cookie") with any browsers. I'm surprised to hear
that you've had problems with it. You might simply try giving up the use of
a cookie for this, and encode the return URL in a query string instead.
This is guaranteed to work regardless of browser, but you'll have to pass
this information between pages (a reasonable trade off for choosing to
support silly browsers, I suppose).
Hope that helps!
[ snip ]
