httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sameer <sam...@c2.net>
Subject Re: Thoughts on a 2.0 API
Date Mon, 09 Jun 1997 22:51:23 GMT
	I like the callback method of installing API hooks, as you
describe here. SOme of the phases you propose I think should be at a
different level, say 'connection-close' -- that should go on the
transport protocol API, not the request-processing API.
	I guess we need a list of the various types of APIs:

- Transport protocol API (HTTP-NG module)
- Request processing API (Turning URL + req-headers into resp-headers + body)
- OS Abstraction API

	I'm sure I'm missing stuff.

> Here are some thoughts I've had on the design of an API for Apache
> 2.0. Please feel free to ignore it. I'm mainly talking here, fyi,
> about the API for handling the request. I haven't thought much about
> module loading, configuration handling, that sort of thing, and I
> believe others are. What I've been pondering is the best way to handle
> the "phases" (I'll use this term throughout; other people use
> different words, this is mine) of the request.
> 
> Currently, Apache has the following phases:
> 
> 1. URL->filename translation
> 2. header parse
> 3. access check
> 4. user id check
> 5. auth check
> 6. type check
> 7. fixup phase
> 8. handler phase
> 9. logging phase
> 
> In earlier discussions, assuming we keep a similar request model in
> 2.0 (which I think is likely), we've discussed having at least the
> following phases:
> 
> 1. "connection open" phase
> 2. begin request phase
> 3. URL->URL translation
> 4. URL->filename translation
> 5. filename->filename translation
> 6. header parse phase
> 7. access check
> 8. user id check
> 9. auth check
> 10. type check
> 11. fixup phase
> 12. handler phase
> 13. . pre-header phase
> 14. . post-header (pre-body) phase
> 15. end request phase
> 16. logging phase
> 17. end connection phase
> 18. "connection closed" phase
> 
> And I may be missing some we've discussed. The point is, there are
> (will be) twice as many request phases in 2.0 as in 1.x. We've also
> had problems with the nature of the current model. Currently, most
> phases are run always, with the exception of the handler phase, which
> is keyed off of handler/media type. Apache was designed mainly to
> serve GET requests, and it doesn't do as well as it could when handing
> POSTs, PUTs, and whatever else. Especially with regards to
> HTTP/1.1. It would be useful to know what methods a given handler
> should handle *before* it's run. And some handlers in some modules
> don't handle non-GETs correctly. There are other, similar problems.
> 
> Also, the phase functions in the module are static; they're determined
> beforehand, and added into the server when the module is loaded. With
> a lot of phases, and a lot of permutations of these, it may not be the
> best idea to do it this way. For one thing, a module_rec entry with
> twenty lines in each module just looks ugly, and adding more phases
> just gets ugly. Especially if there are phases not supported by the
> API (this wouldn't happen with Apache, but if the API was cloned --
> see my previous "Molly and the Apache API" email -- it might. Also,
> certain phases might be turned off by the server for performance
> reasons?) Along a similar vein, each module having 20+ functions that
> have to be checked and called for each request... if you have a lot of
> modules, that could quite possibly slow down the server. Especially
> for modules that have features that are by default turned off.
> 
> What is the solution? How about making the API dynamic? A module_rec
> might just have an initializer phase (or two - we've discussed
> "run-on-fork" initializers as well as the "run-on-start" we have now),
> and a command table (or something). The initialization function would
> call things like:
> 
>    add_request_phase(&handler_func, HANDLER_PHASE, "text/html", M_GET|M_POST);
>    add_request_phase(&type_func, CHECK_TYPE_PHASE, NULL, M_ANY);
> 
> These might also be called from command functions (i.e., putting in
> the first "AddType" command would cause mod_mime to add a check_type
> phase). Of course, these would be stored like per-dir configs are now,
> and merged for the request. In fact, add_request_phase might even be
> called *during* the request. For example, a connection-open phase that
> activates SSL might add a connection-close phase that turned off SSL
> (I don't know exactly how SSL works, so this might not be a good
> example) -- this way, non-SSL requests wouldn't bother calling the
> connection-close phase's function.
> 
> This would also allow the server to optimize its request handling;
> because the phase functions would be distinct from the modules, it
> would know that it didn't have any check access functions (for
> example), so it wouldn't bother checking for them. It might also solve
> the "which modules comes first?" problem - maybe the add_request_phase
> function might include a priority value (each priority would be
> defined by the API, of course). Maybe even a run-all/run-one
> indication, unlike now, where some phases run all of the functions,
> and some run until they hit an OK (i.e, all the run-all functions
> would run, then the run-one ones). And the server could also sort the
> functions in an order that makes sense (this would apply probably only
> to those functions added at server config, not during the request):
> putting the wildcard handlers last, so it wouldn't have to run through
> the list twice.
> 
> It would also allow (as I mentioned earlier), an implementation of the
> API to leave stuff out. For example, if the server didn't support the
> CHECK_ACCESS phase, it could return -1 to the add_request_phase()
> function. The module would check the return value, and if it was
> non-zero, would return an error or something. (although I must admit,
> exceptions would be nice here). This would also allow us (the Apache
> Group) to add additional phases without breaking backwards and
> forwards compatibility for existing modules. In fact, I think that
> should be a goal for 2.0 in general - we should set up rules about
> changing/adding/deleting "public" functions/structures/variables so
> that binary compatibility is sacrificed as little as possible. Again,
> see my "Molly and the Apache API" for why this is a Good Idea.
> 
> Anyway, that's an idea I had. I haven't had much experience with
> software engineering on this scale, so there's a good chance that it's
> a pathetically stupid idea. If so, could someone please tell me?
> 
> -- 
> ________________________________________________________________________
> Alexei Kosut <akosut@nueva.pvt.k12.ca.us>      The Apache HTTP Server
> URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/
> 


-- 
Sameer Parekh					Voice:   510-986-8770
President					FAX:     510-986-8777
C2Net
http://www.c2.net/				sameer@c2.net

Mime
View raw message