http_main.inc 6.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160
  1. { Licensed to the Apache Software Foundation (ASF) under one or more
  2. * contributor license agreements. See the NOTICE file distributed with
  3. * this work for additional information regarding copyright ownership.
  4. * The ASF licenses this file to You under the Apache License, Version 2.0
  5. * (the "License"); you may not use this file except in compliance with
  6. * the License. You may obtain a copy of the License at
  7. *
  8. * http://www.apache.org/licenses/LICENSE-2.0
  9. *
  10. * Unless required by applicable law or agreed to in writing, software
  11. * distributed under the License is distributed on an "AS IS" BASIS,
  12. * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  13. * See the License for the specific language governing permissions and
  14. * limitations under the License.
  15. }
  16. {
  17. * Routines in http_main.c which other code --- in particular modules ---
  18. * may want to call. Right now, that's limited to timeout handling.
  19. * There are two functions which modules can call to trigger a timeout
  20. * (with the per-virtual-server timeout duration); these are hard_timeout
  21. * and soft_timeout.
  22. *
  23. * The difference between the two is what happens when the timeout
  24. * expires (or earlier than that, if the client connection aborts) ---
  25. * a soft_timeout just puts the connection to the client in an
  26. * "aborted" state, which will cause http_protocol.c to stop trying to
  27. * talk to the client, but otherwise allows the code to continue normally.
  28. * hard_timeout(), by contrast, logs the request, and then aborts it
  29. * completely --- longjmp()ing out to the accept() loop in http_main.
  30. * Any resources tied into the request's resource pool will be cleaned up;
  31. * everything that isn't will leak.
  32. *
  33. * soft_timeout() is recommended as a general rule, because it gives your
  34. * code a chance to clean up. However, hard_timeout() may be the most
  35. * convenient way of dealing with timeouts waiting for some external
  36. * resource other than the client, if you can live with the restrictions.
  37. *
  38. * (When a hard timeout is in scope, critical sections can be guarded
  39. * with block_alarms() and unblock_alarms() --- these are declared in
  40. * alloc.c because they are most often used in conjunction with
  41. * routines to allocate something or other, to make sure that the
  42. * cleanup does get registered before any alarm is allowed to happen
  43. * which might require it to be cleaned up; they * are, however,
  44. * implemented in http_main.c).
  45. *
  46. * NOTE! It's not "fair" for a hard_timeout to be in scope through calls
  47. * across modules. Your module code really has no idea what other modules may
  48. * be present in the server, and they may not take too kindly to having a
  49. * longjmp() happen -- it could result in corrupted state. Heck they may not
  50. * even take to kindly to a soft_timeout()... because it can cause EINTR to
  51. * happen on pretty much any syscall, and unless all the libraries and modules
  52. * in use are known to deal well with EINTR it could cause corruption as well.
  53. * But things are likely to do much better with a soft_timeout in scope than a
  54. * hard_timeout.
  55. *
  56. * A module MAY NOT use a hard_timeout() across * sub_req_lookup_xxx()
  57. * functions, or across run_sub_request() functions. A module SHOULD NOT use a
  58. * soft_timeout() in either of these cases, but sometimes there's just no
  59. * choice.
  60. *
  61. * kill_timeout() will disarm either variety of timeout.
  62. *
  63. * reset_timeout() resets the timeout in progress.
  64. }
  65. procedure ap_start_shutdown();
  66. {$IFDEF WINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF} external LibHTTPD;
  67. procedure ap_start_restart(param: cint);
  68. {$IFDEF WINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF} external LibHTTPD;
  69. procedure ap_hard_timeout(p: PAnsiChar; r: Prequest_rec);
  70. {$IFDEF WINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF} external LibHTTPD;
  71. procedure ap_keepalive_timeout(p: PAnsiChar; r: Prequest_rec);
  72. {$IFDEF WINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF} external LibHTTPD;
  73. procedure ap_soft_timeout(p: PAnsiChar; r: Prequest_rec);
  74. {$IFDEF WINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF} external LibHTTPD;
  75. procedure ap_kill_timeout(r: Prequest_rec);
  76. {$IFDEF WINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF} external LibHTTPD;
  77. procedure ap_reset_timeout(r: Prequest_rec);
  78. {$IFDEF WINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF} external LibHTTPD;
  79. //procedure ap_child_terminate(r: Prequest_rec);
  80. // {$IFDEF WINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF} external LibHTTPD;
  81. procedure ap_sync_scoreboard_image();
  82. {$IFDEF WINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF} external LibHTTPD;
  83. function ap_update_child_status(child_num, status: cint; r: Prequest_rec): cint;
  84. {$IFDEF WINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF} external LibHTTPD;
  85. { void ap_time_process_request(int child_num, int status); }
  86. type
  87. fn_t = procedure (param: cint);
  88. function ap_set_callback_and_alarm(fn: fn_t; x: cint): cuint;
  89. {$IFDEF WINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF} external LibHTTPD;
  90. function ap_check_alarm(): cint;
  91. {$IFDEF WINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF} external LibHTTPD;
  92. { void setup_signal_names(AnsiChar *prefix);}
  93. { functions for determination and setting of accept() mutexing }
  94. {AnsiChar *ap_default_mutex_method(void);
  95. AnsiChar *ap_init_mutex_method(AnsiChar *t);}
  96. {$ifndef NO_OTHER_CHILD}
  97. {
  98. * register another_child -- a child which the main loop keeps track of
  99. * and knows it is different than the rest of the scoreboard.
  100. *
  101. * pid is the pid of the child.
  102. *
  103. * maintenance is a function that is invoked with a reason, the data
  104. * pointer passed here, and when appropriate a status result from waitpid().
  105. *
  106. * write_fd is an fd that is probed for writing by select() if it is ever
  107. * unwritable, then maintenance is invoked with reason OC_REASON_UNWRITABLE.
  108. * This is useful for log pipe children, to know when they've blocked. To
  109. * disable this feature, use -1 for write_fd.
  110. }
  111. type
  112. maintenance_t = procedure (reason: cint; data: Pointer; status: ap_wait_t);
  113. procedure ap_register_other_child(pid: cint;
  114. maintenance: maintenance_t; data: Pointer; write_fd: cint);
  115. {$IFDEF WINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF} external LibHTTPD;
  116. const
  117. OC_REASON_DEATH = 0; { child has died, caller must call
  118. * unregister still }
  119. OC_REASON_UNWRITABLE = 1; { write_fd is unwritable }
  120. OC_REASON_RESTART = 2; { a restart is occuring, perform
  121. * any necessary cleanup (including
  122. * sending a special signal to child)
  123. }
  124. OC_REASON_UNREGISTER = 3; { unregister has been called, do
  125. * whatever is necessary (including
  126. * kill the child) }
  127. OC_REASON_LOST = 4; { somehow the child exited without
  128. * us knowing ... buggy os? }
  129. {
  130. * unregister another_child. Note that the data pointer is used here, and
  131. * is assumed to be unique' per other_child. This is because the pid and
  132. * write_fd are possibly killed off separately.
  133. }
  134. procedure ap_unregister_other_child(data: Pointer);
  135. {$IFDEF WINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF} external LibHTTPD;
  136. {$endif}