shibboleth-dev - Re: Proposed (draft) Webserver API
Subject: Shibboleth Developers
List archive
- From: Derek Atkins <>
- To: "Scott Cantor" <>
- Cc: <>
- Subject: Re: Proposed (draft) Webserver API
- Date: Thu, 02 Dec 2004 09:40:32 -0500
"Scott Cantor"
<>
writes:
> Right, well, I think the callback object also could represent the state of
> the request as well and store some of the stuff I put into the SHIRE/RM
> classes. The current SHIRE/RM methods might be moved into statics or could
> just be common (not virtual) implementations of methods on the callback
> object.
True. Are you suggesting that we store a callback state object in
some special data of the apache request_rec structure? The way the
various apache methods are called we need to worry about ordering,
cross-calling, and duplicate-calling. We also need to incercept the
basic-auth override, which would require either changing the AuhtType
in the request_rec or somehow attaching our callback to the request_rec.
The only two data I think I need access to (besides the htaccess) is
the key used to detect whether to run the shib_post_handler on apache2
and the authtype for basicHijack. I can probably work around these
two if I think about it harder.
>> Sure it does: LogEvent(). I was modeling it after that. The idea was
>
> LogEvent writes to the Windows event log, which isn't a good place for debug
> or trace oriented information that might plausibly be in a web server error
> log. I don't use it much, and I'm not sure that you would want to implement
> the IIS version of your logging callback to go there.
Yes, I know. I didn't want to use this API for actual debugging
information, only actual failure information. All the debugging
information would use log4cpp. This way we can centralize the
debugging info in the shire log and leave the windows event log (or
apache error_log) with minimal failure events so people see that yes
there WAS a failure accessing some resource.
>> Hmm. Ok, do you need anything other than the status code? Do we need
>> to set the content-type, too, or is it always going to be text/html?
>
> Probably, but I would make it a default that can be overridden just in case.
> I actually would consider using the style I used in the IIS code, and
> basically allow a set of headers to be provided, so that way you get more or
> less full control from the portable layer.
Hmm, so basically you think something like this:
void* sendPage(String msg, pair<String,String> headers[] = null, int code =
200);
> -- Scott
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
PGP key available
- Proposed (draft) Webserver API, Derek Atkins, 12/01/2004
- RE: Proposed (draft) Webserver API, Scott Cantor, 12/01/2004
- Re: Proposed (draft) Webserver API, Derek Atkins, 12/01/2004
- RE: Proposed (draft) Webserver API, Scott Cantor, 12/01/2004
- Re: Proposed (draft) Webserver API, Derek Atkins, 12/02/2004
- RE: Proposed (draft) Webserver API, Scott Cantor, 12/02/2004
- Re: Proposed (draft) Webserver API, Derek Atkins, 12/02/2004
- RE: Proposed (draft) Webserver API, Scott Cantor, 12/02/2004
- Re: Proposed (draft) Webserver API, Derek Atkins, 12/02/2004
- Re: Proposed (draft) Webserver API, Derek Atkins, 12/02/2004
- Re: Proposed (draft) Webserver API, Steven_Carmody, 12/06/2004
- Re: Proposed (draft) Webserver API, Derek Atkins, 12/06/2004
- RE: Proposed (draft) Webserver API, Scott Cantor, 12/06/2004
- Re: Proposed (draft) Webserver API, Derek Atkins, 12/02/2004
- RE: Proposed (draft) Webserver API, Scott Cantor, 12/02/2004
- Re: Proposed (draft) Webserver API, Derek Atkins, 12/02/2004
- RE: Proposed (draft) Webserver API, Scott Cantor, 12/01/2004
- Re: Proposed (draft) Webserver API, Derek Atkins, 12/01/2004
- RE: Proposed (draft) Webserver API, Scott Cantor, 12/01/2004
Archive powered by MHonArc 2.6.16.