本文来自apache网站的同名文章，其作者为 Robert S. Thau只是粗略的浏览并简单的翻译，欢迎大家提出意见，我会改正。我不对译文的正确性做任何保证，我放在这里仅仅是因为我自己可以方便的查阅到这篇文章These are some notes on the Apache API and the data structures you haveto deal with, etc. They are not yet nearly complete, but hopefully,they will help you get your bearings. Keep in mind that the API isstill subject to change as we gain experience with it. (See the TODOfile for what might be coming). However, it will be easy to adaptmodules to any changes that are made. (We have more modules to adaptthan you do).这里有一些你需要注意的，关于ApacheAPI和数据结构的注意事项。它们还没有完成，但是幸运的是，它们将有助于你确定你的方向。需要始终牢记在心的是，API永远可能会被修改，我们也始终能从中得到新的体验。（可以参阅TODO文件，看看会有哪些改变）。但是，这些改变会轻松的兼容更有的模块
A few notes on general pedagogical style here. In the interest ofconciseness, all structure declarations here are incomplete --- thereal ones have more slots, that I'm not telling you about. For the mostpart, these are reserved to one component of the server core oranother, and should be altered by modules with caution. However, insome cases, they really are things I just haven't gotten around to yet.Welcome to the bleeding edge.Finally, here's an outline, to give you some bare idea of what's coming up, and in what order: * Basic concepts. o Handlers, Modules, and Requests o A brief tour of a module * How handlers work o A brief tour of the request_rec o Where request_rec structures come from o Handling requests, declining, and returning error codes o Special considerations for response handlers o Special considerations for authentication handlers o Special considerations for logging handlers * Resource allocation and resource pools * Configuration, commands and the like o Per-directory configuration structures o Command handling o Side notes --- per-server configuration, virtual servers, etc. Basic concepts.We begin with an overview of the basic concepts behind the API, and how they are manifested in the code.Handlers, Modules, and RequestsApache breaks down request handling into a series of steps, more orless the same way the Netscape Server API does (although this API has afew more stages than NetSite does, as hooks for stuff I thought mightbe useful in the future). These are: * URI -> Filename translation * Auth ID checking [is the user who they say they are?] * Auth access checking [is the user authorized here?] * Access checking other than auth * Determining MIME type of the object requested * "Fixups" --- there aren't any of these yet, but the phase isintended as a hook for possible extensions like SetEnv, which don'treally fit well elsewhere. * Actually sending a response back to the client. * Logging the request These phases are handled by looking at each of a succession of modules,looking to see if each of them has a handler for the phase, andattempting invoking it if so. The handler can typically do one of threethings: * Handle the request, and indicate that it has done so by returning the magic constant OK. * Decline to handle the request, by returning the magic integerconstant DECLINED. In this case, the server behaves in all respects asif the handler simply hadn't been there. * Signal an error, by returning one of the HTTP error codes. Thisterminates normal handling of the request, although an ErrorDocumentmay be invoked to try to mop up, and it will be logged in any case. Most phases are terminated by the first module that handles them;however, for logging, "fixups", and non-access authentication checking,all handlers always run (barring an error). Also, the response phase isunique in that modules may declare multiple handlers for it, via adispatch table keyed on the MIME type of the requested object. Modulesmay declare a response-phase handler which can handle any request, bygiving it the key */* (i.e., a wildcard MIME type specification).However, wildcard handlers are only invoked if the server has alreadytried and fail

评论 (0) All

登陆 还没注册？