lighttpd中handle_start_backend钩子(hook)函数的理解
[| 2012/04/25 19:59]
之前按字面意思理解handle_start_backend是说连接后端服务端口(webserver,fastcgi等等),今天发现并非如此。
这个hook是在CON_STATE_HANDLE_REQUEST_HEADER状态时,
如果con->mode仍旧是DIRECT类型且con->physical.path为空,会先调用:
plugins_call_handle_uri_raw
plugins_call_handle_uri_clean
plugins_call_handle_docroot
plugins_call_handle_physical
如果con->mode还是DIRECT,那么会判断con->physical.path指定的文件是否存在,
若存在,如果是软链但是con->conf.follow_symlink为0,那么403,如果是目录但请求url不是路径名,则301跳转到目录路径(在末尾加/)
若无权限访问,返回403
若找不到文件,返回404
若ENOTDIR(对文件做了目录操作),则考虑path_info
若EMFILE(进程句柄不足),则返回HANDLER_WAIT_FOR_FD
若不是以上情况,打印错误日志,返回500
如果con->physical.path存在且无错误发生,或为ENOTDIR,那么又判断了一次是否存在(这里代码设计比较恶心)
如果是普通文件且没有软链问题,那么break出去执行plugins_call_handle_start_backend。
反之则一直向上遍历,直到遍历到一个真实存在的文件,如果找不到,那么404,如果找到了,将pathinfo串放入con->request.pathinfo。然后截短con->uri.path。
然后才会去调用plugins_call_handle_start_backend。
所以对于很多动态请求是不会调用plugins_call_handle_start_backend的。
这个钩子被mod_access调用用来实现deny_all功能。
被mod_indexfile调用用来实现默认文件功能(请求/时映射到index.php等)
这个hook是在CON_STATE_HANDLE_REQUEST_HEADER状态时,
如果con->mode仍旧是DIRECT类型且con->physical.path为空,会先调用:
plugins_call_handle_uri_raw
plugins_call_handle_uri_clean
plugins_call_handle_docroot
plugins_call_handle_physical
如果con->mode还是DIRECT,那么会判断con->physical.path指定的文件是否存在,
若存在,如果是软链但是con->conf.follow_symlink为0,那么403,如果是目录但请求url不是路径名,则301跳转到目录路径(在末尾加/)
若无权限访问,返回403
若找不到文件,返回404
若ENOTDIR(对文件做了目录操作),则考虑path_info
若EMFILE(进程句柄不足),则返回HANDLER_WAIT_FOR_FD
若不是以上情况,打印错误日志,返回500
如果con->physical.path存在且无错误发生,或为ENOTDIR,那么又判断了一次是否存在(这里代码设计比较恶心)
如果是普通文件且没有软链问题,那么break出去执行plugins_call_handle_start_backend。
反之则一直向上遍历,直到遍历到一个真实存在的文件,如果找不到,那么404,如果找到了,将pathinfo串放入con->request.pathinfo。然后截短con->uri.path。
然后才会去调用plugins_call_handle_start_backend。
所以对于很多动态请求是不会调用plugins_call_handle_start_backend的。
这个钩子被mod_access调用用来实现deny_all功能。
被mod_indexfile调用用来实现默认文件功能(请求/时映射到index.php等)