mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2025-01-02 18:22:04 +00:00
DOC: assorted typo fixes in the documentation
This is the third round of cleanups in various docs
This commit is contained in:
Ilya Shipitsin
Willy Tarreau
parent
7b5e136458
commit
2075ca8a93
2
BRANCHES
2
BRANCHES
@ -191,7 +191,7 @@ Thus the release cycle from 1.8 to 2.2 should look like this:
|
||||
`---+---+---+-----+-------+-----------+---------------+------> 1.8 LTS
|
||||
|
||||
In short the non-LTS odd releases can be seen as technological previews of the
|
||||
next feature release, and will be terminated much ealier. The plan is to barely
|
||||
next feature release, and will be terminated much earlier. The plan is to barely
|
||||
let them overlap with the next non-LTS release, allowing advanced users to
|
||||
always have the choice between the last two major releases.
|
||||
|
||||
|
||||
@ -119,7 +119,7 @@ Identified handshake handlers for incoming connections :
|
||||
- HH_ACCEPT_PROXY (waits for PROXY line and parses it)
|
||||
- HH_TCP_RULES (processes TCP rules)
|
||||
- HH_SSL_HS (starts SSL handshake)
|
||||
- HH_ACCEPT_SESSION (instanciates a session)
|
||||
- HH_ACCEPT_SESSION (instantiates a session)
|
||||
|
||||
Identified handshake handlers for outgoing connections :
|
||||
- HH_SEND_PROXY (tries to build and send the PROXY line)
|
||||
|
||||
@ -97,7 +97,7 @@
|
||||
before the connection timeout so that an unused connection is verified before
|
||||
being killed. Abnormal requests must be dealt with using RST_STREAM.
|
||||
|
||||
- ALPN : ALPN must be observed onthe client side, and transmitted to the server
|
||||
- ALPN : ALPN must be observed on the client side, and transmitted to the server
|
||||
side.
|
||||
|
||||
- proxy protocol : proxy protocol makes little to no sense in a multiplexed
|
||||
@ -134,7 +134,7 @@
|
||||
to H2 behind. This can cause some trouble when passing H2 requests to H1
|
||||
proxies, because there's no way to know if the request should contain scheme
|
||||
and authority in H1 or not based on the H2 request. Thus a "proxy" option
|
||||
will have to be explicitly mentionned on HTTP/1 server lines. One of the
|
||||
will have to be explicitly mentioned on HTTP/1 server lines. One of the
|
||||
problem that it creates is that it's not longer possible to pass H/1 requests
|
||||
to H/1 proxies without an explicit configuration. Maybe a table of the
|
||||
various combinations is needed.
|
||||
|
||||
@ -630,7 +630,7 @@ but fail.
|
||||
<------------------> <---------->
|
||||
o i
|
||||
|
||||
There is this correspondance between old and new fields (some will involve a
|
||||
There is this correspondence between old and new fields (some will involve a
|
||||
knowledge of a channel when the output byte count is required) :
|
||||
|
||||
Old | New
|
||||
|
||||
@ -116,7 +116,7 @@ Identified handshake handlers for incoming connections :
|
||||
- HH_ACCEPT_PROXY (waits for PROXY line and parses it)
|
||||
- HH_TCP_RULES (processes TCP rules)
|
||||
- HH_SSL_HS (starts SSL handshake)
|
||||
- HH_ACCEPT_SESSION (instanciates a session)
|
||||
- HH_ACCEPT_SESSION (instantiates a session)
|
||||
|
||||
Identified handshake handlers for outgoing connections :
|
||||
- HH_SEND_PROXY (tries to build and send the PROXY line)
|
||||
|
||||
@ -9,7 +9,7 @@ Listener
|
||||
|
||||
A listener is the entity which is part of a frontend and which accepts
|
||||
connections. There are as many listeners as there are ip:port couples.
|
||||
There is at least one listener instanciated for each "bind" entry, and
|
||||
There is at least one listener instantiated for each "bind" entry, and
|
||||
port ranges will lead to as many listeners as there are ports in the
|
||||
range. A listener just has a listening file descriptor ready to accept
|
||||
incoming connections and to dispatch them to upper layers.
|
||||
@ -18,8 +18,8 @@ incoming connections and to dispatch them to upper layers.
|
||||
Initiator
|
||||
---------
|
||||
|
||||
An initiator is instanciated for each incoming connection on a listener. It may
|
||||
also be instanciated by a task pretending to be a client. An initiator calls
|
||||
An initiator is instantiated for each incoming connection on a listener. It may
|
||||
also be instantiated by a task pretending to be a client. An initiator calls
|
||||
the next stage's accept() callback to present it with the parameters of the
|
||||
incoming connection.
|
||||
|
||||
@ -39,7 +39,7 @@ side and other ones on the connector side. If additional buffers are needed for
|
||||
such transforms, those buffers cannot replace the session's buffers, but they
|
||||
may complete them.
|
||||
|
||||
A session only needs to be instanciated when forwarding of data is required
|
||||
A session only needs to be instantiated when forwarding of data is required
|
||||
between two sides. Accepting and filtering on layer 4 information only does not
|
||||
require a session.
|
||||
|
||||
@ -76,7 +76,7 @@ side of diagrams.
|
||||
Connection
|
||||
----------
|
||||
|
||||
A connection is the entity instanciated by a connector. It may be composed of
|
||||
A connection is the entity instantiated by a connector. It may be composed of
|
||||
multiple stages linked together. Generally it is the part of the stream
|
||||
interface holding a file descriptor, but it can also be a processing block or a
|
||||
transformation block terminated by a connection. A connection presents a
|
||||
@ -86,11 +86,11 @@ server-side interface.
|
||||
2) Sequencing
|
||||
-------------
|
||||
|
||||
Upon startup, listeners are instanciated by the configuration. When an incoming
|
||||
Upon startup, listeners are instantiated by the configuration. When an incoming
|
||||
connection reaches a listening file descriptor, its read() callback calls the
|
||||
corresponding listener's accept() function which instanciates an initiator and
|
||||
corresponding listener's accept() function which instantiates an initiator and
|
||||
in turn recursively calls upper layers' accept() callbacks until
|
||||
accept_session() is called. accept_session() instanciates a new session which
|
||||
accept_session() is called. accept_session() instantiates a new session which
|
||||
starts protocol analysis via process_session(). When all protocol analysis is
|
||||
done, process_session() calls the connect() callback of the connector in order
|
||||
to get a connection.
|
||||
|
||||
@ -84,7 +84,7 @@ filters are also chained, frontend ones called first. Even if the filters
|
||||
processing is serialized, each filter will bahave as it was alone (unless it was
|
||||
developed to be aware of other filters). For all that, some constraints are
|
||||
imposed to filters, especially when data exchanged between the client and the
|
||||
server are processed. We will dicuss again these contraints when we will tackle
|
||||
server are processed. We will dicuss again these constraints when we will tackle
|
||||
the subject of writing a filter.
|
||||
|
||||
|
||||
@ -93,7 +93,7 @@ the subject of writing a filter.
|
||||
---------------------
|
||||
|
||||
To use a filter, you must use the parameter 'filter' followed by the filter name
|
||||
and, optionnaly, its configuration in the desired listen, frontend or backend
|
||||
and, optionally, its configuration in the desired listen, frontend or backend
|
||||
section. For example:
|
||||
|
||||
listen test
|
||||
@ -123,7 +123,7 @@ Multiple filter lines can be used in a proxy section to chain filters. Filters
|
||||
will be called in the declaration order.
|
||||
|
||||
Some filters can support implicit declarartions in certain circumstances
|
||||
(without the filter line). This is not recommanded for new features but are
|
||||
(without the filter line). This is not recommended for new features but are
|
||||
useful for existing ones moved in a filter, for backward compatibility
|
||||
reasons. Implicit declarartions are supported when there is only one filter used
|
||||
on a proxy. When several filters are used, explicit declarartions are mandatory.
|
||||
@ -131,7 +131,7 @@ The HTTP compression filter is one of these filters. Alone, using 'compression'
|
||||
keywords is enough to use it. But when at least a second filter is used, a
|
||||
filter line must be added.
|
||||
|
||||
# filter line is optionnal
|
||||
# filter line is optional
|
||||
listen t1
|
||||
bind *:80
|
||||
compression algo gzip
|
||||
@ -306,7 +306,7 @@ Filter instances attached to a stream are stored in the field
|
||||
*
|
||||
* 2D-Array fields are used to store info per channel. The first index
|
||||
* stands for the request channel, and the second one for the response
|
||||
* channel. Especially, <next> and <fwd> are offets representing amount of
|
||||
* channel. Especially, <next> and <fwd> are offsets representing amount of
|
||||
* data that the filter are, respectively, parsed and forwarded on a
|
||||
* channel. Filters can access these values using FLT_NXT and FLT_FWD
|
||||
* macros.
|
||||
@ -445,7 +445,7 @@ In the previous example, we expect to read a filter line as follows:
|
||||
filter my_filter name MY_NAME ...
|
||||
|
||||
|
||||
Optionnaly, by implementing the 'flt_ops.check' callback, you add a step to
|
||||
Optionally, by implementing the 'flt_ops.check' callback, you add a step to
|
||||
check the internal configuration of your filter after the parsing phase, when
|
||||
the HAProxy configuration is fully defined. For example:
|
||||
|
||||
@ -492,7 +492,7 @@ Here is an example:
|
||||
return 0;
|
||||
}
|
||||
|
||||
/* Free ressources allocated by the trace filter. */
|
||||
/* Free resources allocated by the trace filter. */
|
||||
static void
|
||||
my_filter_deinit(struct proxy *px, struct flt_conf *fconf)
|
||||
{
|
||||
@ -591,7 +591,7 @@ For example:
|
||||
}
|
||||
|
||||
|
||||
WARNING: Handling the streams creation and destuction is only possible for
|
||||
WARNING: Handling the streams creation and destruction is only possible for
|
||||
filters defined on proxies with the frontend capability.
|
||||
|
||||
In addition, it is possible to handle creation and destruction of filter
|
||||
|
||||
@ -9,7 +9,7 @@
|
||||
1. Background
|
||||
|
||||
Historically, HAProxy stored HTTP messages in a raw fashion in buffers, keeping
|
||||
parsing information separatly in a "struct http_msg" owned by the stream. It was
|
||||
parsing information separately in a "struct http_msg" owned by the stream. It was
|
||||
optimized to the data transfer, but not so much for rewrites. It was also HTTP/1
|
||||
centered. While it was the only HTTP version supported, it was not a
|
||||
problem. But with the rise of HTTP/2, it starts to be hard to still use this
|
||||
@ -26,7 +26,7 @@ So, to address all these problems, we decided to replace the old raw
|
||||
representation by a version-agnostic and self-structured internal HTTP
|
||||
representation, the HTX. As an additional benefit, with this new representation,
|
||||
the message parsing and its processing are now separated, making all the HTTP
|
||||
analysis simplier and cleaner. The parsing of HTTP messages is now handled by
|
||||
analysis simpler and cleaner. The parsing of HTTP messages is now handled by
|
||||
the multiplexers (h1 or h2).
|
||||
|
||||
|
||||
@ -37,7 +37,7 @@ followed by a contiguous array with some parts of the message. These parts are
|
||||
called blocks. A block is composed of metadata (htx_blk) and an associated
|
||||
payload. Blocks' metadata are stored starting from the end of the array while
|
||||
their payload are stored at the beginning. Blocks' metadata are often simply
|
||||
called blocks. it is a misuse of language that's simplify explainations.
|
||||
called blocks. it is a misuse of language that's simplify explanations.
|
||||
|
||||
Internally, this structure is "hidden" in a buffer. This way, there are few
|
||||
changes into intermediate layers (stream-interface and channels). They still
|
||||
@ -78,7 +78,7 @@ relatively to the beginning of the blocks array.
|
||||
at the position N at the position 1 at the position 0
|
||||
|
||||
|
||||
In the HTX struture, 3 "special" positions are stored:
|
||||
In the HTX structure, 3 "special" positions are stored:
|
||||
|
||||
- tail : Position of the newest inserted block
|
||||
- head : Position of the oldest inserted block
|
||||
@ -209,7 +209,7 @@ An HTX message is typically composed of following blocks, in this order :
|
||||
Only one HTTP request at a time can be stored in an HTX message. For HTTP
|
||||
response, it is more complicated. Only one "final" response can be stored in an
|
||||
HTX message. It is a response with status-code 101 or greater or equal to
|
||||
200. But it may be preceeded by several 1xx informational responses. Such
|
||||
200. But it may be preceded by several 1xx informational responses. Such
|
||||
responses are part of the same HTX message, so there is no end-of-message marker
|
||||
for them.
|
||||
|
||||
|
||||
@ -110,7 +110,7 @@ It becomes visible that the mux will not always be welcome to decode incoming
|
||||
data because it will sometimes imply extra memory copies and/or usage for no
|
||||
benefit.
|
||||
|
||||
Ideally, when when a stream is instanciated based on incoming data, these
|
||||
Ideally, when when a stream is instantiated based on incoming data, these
|
||||
incoming data should be passed and the upper layers called, but it should then
|
||||
be up these upper layers to peek more data in certain circumstances. Typically
|
||||
if the pending connection data are larger than what is expected to be passed
|
||||
@ -179,7 +179,7 @@ not implementing everything yet.
|
||||
Short term proposal : a channel has access to a buffer and a pipe. A non-empty
|
||||
buffer is either in structured message format OR raw stream format. Only the
|
||||
channel knows. However a structured buffer MAY contain raw data in a properly
|
||||
formated way (using the envelope defined by the structured message format).
|
||||
formatted way (using the envelope defined by the structured message format).
|
||||
|
||||
By default, when a demux writes to a CS rxbuf, it will try to use the lowest
|
||||
possible level for what is being done (i.e. splice if possible, otherwise raw
|
||||
@ -269,7 +269,7 @@ Short term implementation :
|
||||
|
||||
5) use the flags to enforce receipt of data only when necessary
|
||||
|
||||
We should be able to end up with sequencial receipt in H2 modelling what is
|
||||
We should be able to end up with sequential receipt in H2 modelling what is
|
||||
needed for other protocols without interfering with the native H1 devs.
|
||||
|
||||
|
||||
|
||||
@ -311,7 +311,7 @@ Core class
|
||||
|
||||
**context**: body, init, task, action, sample-fetch, converter
|
||||
|
||||
Returns HAProxy core informations. We can found information like the uptime,
|
||||
Returns HAProxy core information. We can found information like the uptime,
|
||||
the pid, memory pool usage, tasks number, ...
|
||||
|
||||
These information are also returned by the management socket via the command
|
||||
@ -792,7 +792,7 @@ Core class
|
||||
:returns: boolean, true if the network of the addresses match, else returns
|
||||
false.
|
||||
|
||||
Match two networks. For example "127.0.0.1/32" matchs "127.0.0.0/8". The order
|
||||
Match two networks. For example "127.0.0.1/32" matches "127.0.0.0/8". The order
|
||||
of network is not important.
|
||||
|
||||
.. js:function:: core.tokenize(str, separators [, noblank])
|
||||
@ -1137,7 +1137,7 @@ Concat class
|
||||
|
||||
For each concatenation, Lua:
|
||||
* allocate memory for the result,
|
||||
* catenate the two string copying the strings in the new memory bloc,
|
||||
* catenate the two string copying the strings in the new memory block,
|
||||
* free the old memory block containing the string which is no longer used.
|
||||
This process does many memory move, allocation and free. In addition, the
|
||||
memory is not really freed, it is just mark mark as unused and wait for the
|
||||
@ -1176,7 +1176,7 @@ Concat class
|
||||
This function adds a string to the current concatenated string.
|
||||
|
||||
:param class_concat concat: A :ref:`concat_class` which contains the currently
|
||||
builded string.
|
||||
built string.
|
||||
:param string string: A new string to concatenate to the current built
|
||||
string.
|
||||
|
||||
@ -1185,7 +1185,7 @@ Concat class
|
||||
This function returns the concatenated string.
|
||||
|
||||
:param class_concat concat: A :ref:`concat_class` which contains the currently
|
||||
builded string.
|
||||
built string.
|
||||
:returns: the concatenated string
|
||||
|
||||
.. _fetches_class:
|
||||
@ -1214,7 +1214,7 @@ Fetches class
|
||||
connections established,
|
||||
* client information like ip source or destination,
|
||||
* deal with stick tables,
|
||||
* Established SSL informations,
|
||||
* Established SSL information,
|
||||
* HTTP information like headers or method.
|
||||
|
||||
.. code-block:: lua
|
||||
@ -1278,7 +1278,7 @@ Channel class
|
||||
This function returns a string that contain the entire buffer. The data is
|
||||
not remove from the buffer and can be reprocessed later.
|
||||
|
||||
If the buffer cant receive more data, a 'nil' value is returned.
|
||||
If the buffer can't receive more data, a 'nil' value is returned.
|
||||
|
||||
:param class_channel channel: The manipulated Channel.
|
||||
:returns: a string containing all the available data or nil.
|
||||
@ -1288,7 +1288,7 @@ Channel class
|
||||
This function returns a string that contain the entire buffer. The data is
|
||||
consumed from the buffer.
|
||||
|
||||
If the buffer cant receive more data, a 'nil' value is returned.
|
||||
If the buffer can't receive more data, a 'nil' value is returned.
|
||||
|
||||
:param class_channel channel: The manipulated Channel.
|
||||
:returns: a string containing all the available data or nil.
|
||||
@ -1299,7 +1299,7 @@ Channel class
|
||||
data is consumed. If the data returned doesn't contains a final '\n' its
|
||||
assumed than its the last available data in the buffer.
|
||||
|
||||
If the buffer cant receive more data, a 'nil' value is returned.
|
||||
If the buffer can't receive more data, a 'nil' value is returned.
|
||||
|
||||
:param class_channel channel: The manipulated Channel.
|
||||
:returns: a string containing the available line or nil.
|
||||
@ -2230,7 +2230,7 @@ Map class
|
||||
.. js:attribute:: Map._int
|
||||
|
||||
See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
|
||||
samples" ans subchapter "ACL basics" to understand this pattern matching
|
||||
samples" and subchapter "ACL basics" to understand this pattern matching
|
||||
method.
|
||||
|
||||
Note that :js:attr:`Map.int` is also available for compatibility.
|
||||
@ -2238,7 +2238,7 @@ Map class
|
||||
.. js:attribute:: Map._ip
|
||||
|
||||
See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
|
||||
samples" ans subchapter "ACL basics" to understand this pattern matching
|
||||
samples" and subchapter "ACL basics" to understand this pattern matching
|
||||
method.
|
||||
|
||||
Note that :js:attr:`Map.ip` is also available for compatibility.
|
||||
@ -2246,7 +2246,7 @@ Map class
|
||||
.. js:attribute:: Map._str
|
||||
|
||||
See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
|
||||
samples" ans subchapter "ACL basics" to understand this pattern matching
|
||||
samples" and subchapter "ACL basics" to understand this pattern matching
|
||||
method.
|
||||
|
||||
Note that :js:attr:`Map.str` is also available for compatibility.
|
||||
@ -2254,7 +2254,7 @@ Map class
|
||||
.. js:attribute:: Map._beg
|
||||
|
||||
See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
|
||||
samples" ans subchapter "ACL basics" to understand this pattern matching
|
||||
samples" and subchapter "ACL basics" to understand this pattern matching
|
||||
method.
|
||||
|
||||
Note that :js:attr:`Map.beg` is also available for compatibility.
|
||||
@ -2262,7 +2262,7 @@ Map class
|
||||
.. js:attribute:: Map._sub
|
||||
|
||||
See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
|
||||
samples" ans subchapter "ACL basics" to understand this pattern matching
|
||||
samples" and subchapter "ACL basics" to understand this pattern matching
|
||||
method.
|
||||
|
||||
Note that :js:attr:`Map.sub` is also available for compatibility.
|
||||
@ -2270,7 +2270,7 @@ Map class
|
||||
.. js:attribute:: Map._dir
|
||||
|
||||
See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
|
||||
samples" ans subchapter "ACL basics" to understand this pattern matching
|
||||
samples" and subchapter "ACL basics" to understand this pattern matching
|
||||
method.
|
||||
|
||||
Note that :js:attr:`Map.dir` is also available for compatibility.
|
||||
@ -2278,7 +2278,7 @@ Map class
|
||||
.. js:attribute:: Map._dom
|
||||
|
||||
See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
|
||||
samples" ans subchapter "ACL basics" to understand this pattern matching
|
||||
samples" and subchapter "ACL basics" to understand this pattern matching
|
||||
method.
|
||||
|
||||
Note that :js:attr:`Map.dom` is also available for compatibility.
|
||||
@ -2286,13 +2286,13 @@ Map class
|
||||
.. js:attribute:: Map._end
|
||||
|
||||
See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
|
||||
samples" ans subchapter "ACL basics" to understand this pattern matching
|
||||
samples" and subchapter "ACL basics" to understand this pattern matching
|
||||
method.
|
||||
|
||||
.. js:attribute:: Map._reg
|
||||
|
||||
See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
|
||||
samples" ans subchapter "ACL basics" to understand this pattern matching
|
||||
samples" and subchapter "ACL basics" to understand this pattern matching
|
||||
method.
|
||||
|
||||
Note that :js:attr:`Map.reg` is also available for compatibility.
|
||||
@ -2370,7 +2370,7 @@ AppletHTTP class
|
||||
|
||||
This attribute contains a Fetches class object. Note that the
|
||||
applet execution place cannot access to a valid HAProxy core HTTP
|
||||
transaction, so some sample fetches related to the HTTP dependant
|
||||
transaction, so some sample fetches related to the HTTP dependent
|
||||
values (hdr, path, ...) are not available.
|
||||
|
||||
.. js:attribute:: AppletHTTP.sf
|
||||
@ -2380,7 +2380,7 @@ AppletHTTP class
|
||||
This attribute contains a Fetches class object. The functions of
|
||||
this object returns always a string. Note that the applet
|
||||
execution place cannot access to a valid HAProxy core HTTP
|
||||
transaction, so some sample fetches related to the HTTP dependant
|
||||
transaction, so some sample fetches related to the HTTP dependent
|
||||
values (hdr, path, ...) are not available.
|
||||
|
||||
.. js:attribute:: AppletHTTP.method
|
||||
@ -2451,7 +2451,7 @@ AppletHTTP class
|
||||
This function add an header in the response. Duplicated headers are not
|
||||
collapsed. The special header *content-length* is used to determinate the
|
||||
response length. If it not exists, a *transfer-encoding: chunked* is set, and
|
||||
all the write from the funcion *AppletHTTP:send()* become a chunk.
|
||||
all the write from the function *AppletHTTP:send()* become a chunk.
|
||||
|
||||
:param class_AppletHTTP applet: An :ref:`applethttp_class`
|
||||
:param string name: the header name
|
||||
@ -2821,7 +2821,7 @@ A lot of useful lua libraries can be found here:
|
||||
|
||||
* `https://lua-toolbox.com/ <https://lua-toolbox.com/>`_
|
||||
|
||||
Redis acces:
|
||||
Redis client library:
|
||||
|
||||
* `https://github.com/nrk/redis-lua <https://github.com/nrk/redis-lua>`_
|
||||
|
||||
|
||||
@ -26,7 +26,7 @@ Why a scripting language in HAProxy
|
||||
|
||||
HAProxy 1.5 makes at possible to do many things using samples, but some people
|
||||
want to more combining results of samples fetches, programming conditions and
|
||||
loops which is not possible. Sometimes people implement these functionnalities
|
||||
loops which is not possible. Sometimes people implement these functionalities
|
||||
in patches which have no meaning outside their network. These people must
|
||||
maintain these patches, or worse we must integrate them in the HAProxy
|
||||
mainstream.
|
||||
@ -285,7 +285,7 @@ Some examples follows. This first one, is a simple addition:
|
||||
lua_arith(L, LUA_OPADD)
|
||||
|
||||
It's easy, we push 1 on the stack, after, we push 2, and finally, we perform an
|
||||
addition. The two top entries of the stack are added, poped, and the result is
|
||||
addition. The two top entries of the stack are added, popped, and the result is
|
||||
pushed. It is a classic way with a stack.
|
||||
|
||||
Now an example for constructing array and objects. It's a little bit more
|
||||
|
||||
Loading…
Reference in New Issue
Block a user