From 06ba0b3c77d4747686e58c0083eb318a579798cf Mon Sep 17 00:00:00 2001 From: Daniel-Constantin Mierla Date: Sun, 16 Apr 2017 09:48:40 +0200 Subject: [PATCH] xhttp: added section ids --- src/modules/xhttp/doc/xhttp_admin.xml | 42 +++++++++++++-------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/src/modules/xhttp/doc/xhttp_admin.xml b/src/modules/xhttp/doc/xhttp_admin.xml index b2de4122294..869a1d5d81a 100644 --- a/src/modules/xhttp/doc/xhttp_admin.xml +++ b/src/modules/xhttp/doc/xhttp_admin.xml @@ -10,13 +10,13 @@ - + &adminguide; - +
Overview - This module provides basic HTTP/1.0 server functionality inside + This module provides basic HTTP/1.0 server functionality inside &kamailio;. SIP and HTTP are very similar protocols, so, practically, the SIP parser can easily handle HTTP requests just by adding a fake Via header. @@ -36,32 +36,32 @@ Note on Latency Because HTTP requests in xhttp are handled - by the same, finite number of SIP worker processes that operate on - SIP messages, the same general principles regarding script execution - speed and throughput should be observed by the writer in + by the same, finite number of SIP worker processes that operate on + SIP messages, the same general principles regarding script execution + speed and throughput should be observed by the writer in event_route[xhttp:request] as in any other - part of the route script. + part of the route script. For example, if you initiate a database query in the HTTP request route that takes a long time to return rows, the SIP worker process in which - the request is handled will be blocked for that time and unable to + the request is handled will be blocked for that time and unable to process other SIP messages. In most typical installations, there are - only a few of these worker processes running. + only a few of these worker processes running. Therefore, it is highly inadvisable to execute particularly slow things in the - event_route[xhttp:request], because the request is not - handled in an asynchronous manner or otherwise peripherally to general - SIP processing. SIP worker threads will block, pending the outcome of the - event route just like any other config script route. + event_route[xhttp:request], because the request is not + handled in an asynchronous manner or otherwise peripherally to general + SIP processing. SIP worker threads will block, pending the outcome of the + event route just like any other config script route. - This is no more or less true for xhttp than it is for - any other block of script in any other scenario, and does not warrant any - extraordinary concern. It nevertheless bears mention here because some - processes with embedded HTTP servers have the request processing take place - "outside" of the main synchronous event sequence, whether by creating + This is no more or less true for xhttp than it is for + any other block of script in any other scenario, and does not warrant any + extraordinary concern. It nevertheless bears mention here because some + processes with embedded HTTP servers have the request processing take place + "outside" of the main synchronous event sequence, whether by creating separate threads or by some other asynchronous handling. That is not the case with xhttp. @@ -114,7 +114,7 @@
Parameters -
+
<varname>url_skip</varname> (str) Regular expression to match the HTTP URL. If there is a match, @@ -134,7 +134,7 @@ modparam("xhttp", "url_skip", "^/RPC2")
-
+
<varname>url_match</varname> (str) Regular expression to match the HTTP URL. If there is no match, @@ -160,7 +160,7 @@ modparam("xhttp", "url_match", "^/sip/")
Functions -
+
<function moreinfo="none">xhttp_reply(code, reason, ctype, body)</function>