{"id":21,"date":"2008-06-25T04:50:44","date_gmt":"2008-06-25T04:50:44","guid":{"rendered":"http:\/\/www.houquner.com\/?p=58"},"modified":"2008-06-25T04:50:44","modified_gmt":"2008-06-25T04:50:44","slug":"relaydconf","status":"publish","type":"post","link":"https:\/\/www.houquner.com\/index.php\/archives\/21","title":{"rendered":"RELAYD.CONF"},"content":{"rendered":"

RELAYD.CONF(5) OpenBSD Programmer’s ManualRELAYD.CONF(5)
\nhttp:\/\/www.openbsd.org\/cgi-bin\/man.cgi?query=relayd.conf&sektion=5<\/a>
\nNAME
\n relayd.conf – relay daemon configuration file
\nDESCRIPTION
\n relayd.conf is the configuration file for the relay daemon, relayd(8).
\nSECTIONS
\n relayd.conf is divided into six main sections:
\n? Macros
\n User-defined variables may be defined and used later, simplifying
\n the configuration file.
\n? Global Configuration
\n Global settings for relayd(8).
\n? Tables
\n Table definitions describe a list of hosts, in a similar fashion to
\n pf(4) tables.? They are used for relay and redirection target se-
\n lection with the described options and health checking on the host
\n they contain.
\n? Redirections
\n Redirections are translated to pf(4) rdr rules for stateful for-
\n warding to a target host from a health-checked table on layer 3.
\n? Relays
\n Relays allow application layer load balancing, SSL acceleration,
\n and general purpose TCP proxying on layer 7.
\n? Protocols
\n Protocols are predefined protocol handlers and settings for relays.
\n? Within the sections, a host address can be specified by IPv4 address,
\n IPv6 address, or DNS hostname.? A port can be specified by number or
\n name.? The port name to number mappings are found in the file
\n \/etc\/services; see services(5) for details.
\n? Comments can be put anywhere in the file using a hash mark (`#’), and ex-
\n tend to the end of the current line.
\n? Additional configuration files can be included with the include keyword,
\n for example:
\n include “\/etc\/relayd.conf.local”
\nMACROS
\n Macros can be defined that will later be expanded in context.? Macro
\n names must start with a letter, and may contain letters, digits, and un-
\n derscores.? Macro names may not be reserved words (for example, table,
\n relay, or timeout).? Macros are not expanded inside quotes.
\n? For example:
\n www1=”10.0.0.1″
\n www2=”10.0.0.2″
\n table <webhosts> {
\n $www1
\n $www2
\n }
\nGLOBAL CONFIGURATION
\n Here are the settings that can be set globally:
\n? demote group
\n Enable the global carp(4) demotion option, resetting the carp de-
\n motion counter for the specified interface group to zero on
\n startup and to 128 on shutdown of the daemon.? For more informa-
\n tion on interface groups, see the group keyword in ifconfig(8).
\n? interval number
\n Set the interval in seconds at which the hosts will be checked.
\n The default interval is 10 seconds.
\n? log (updates|all)
\n Log state notifications after completed host checks.? Either only
\n log the updates to new states or log all state notifications,
\n even if the state didn’t change.? The host state can be up (the
\n health check completed successfully), down (the host is down or
\n didn’t match the check criteria), or unknown (the host is dis-
\n abled or has not been checked yet).
\n? prefork number
\n When using relays, run the specified number of processes to han-
\n dle relayed connections.? This increases the performance and pre-
\n vents delays when connecting to a relay.? relayd(8) runs 5 relay
\n processes by default and every process will handle all configured
\n relays.
\n? send trap
\n Send an SNMP trap when the state of a host changes.? relayd(8)
\n will try to connect to snmpd(8) and request it send a trap to the
\n registered trap receivers; see snmpd.conf(5) for more information
\n about the configuration.
\n? timeout number
\n Set the global timeout in milliseconds for checks.? This can be
\n overriden by the timeout value in the table definitions.? The de-
\n fault interval is 200 milliseconds and it must not exceed the
\n global interval.? Please note that the default value is optimized
\n for checks within the same collision domain – use a higher time-
\n out, such as 1000 milliseconds, for checks of hosts in other sub-
\n nets.
\nTABLES
\n Tables are used to group a set of hosts as the target for redirections or
\n relays; they will be mapped to a pf(4) table for redirections.? Tables
\n may be defined with the following attribute:
\n? disable? Start the table disabled – no hosts will be checked in this
\n table.? The table can be later enabled through relayctl(8).
\n? Each table must contain at least one host; multiple hosts are separated
\n by newline, comma, or whitespace.?Host entries may be defined with the
\n following attribute:
\n? retry number
\n The optional retry option adds a tolerance for failed host checks;
\n the check will be retried for number more times before setting the
\n host state to down.? If this table is used by a relay, it will al-
\n so specify the number of retries for outgoing connection attempts.
\n? For example:
\n table <service> { 192.168.1.1, www.houquner.com, 192.168.2.3 }
\n table <backup> disable { 10.1.5.1 retry 2 }
\n redirect “www” {
\n listen on www.example.com port 80
\n forward to <service> check http “\/” code 200
\n forward to <backup> check http “\/” code 200
\n }
\n? Tables are used by forward to directives in redirections or relays with a
\n set of general options, health-checking rules, and timings; see the
\n REDIRECTIONS and RELAYS sections for more information about the forward
\n context.? Table specific configuration directives are described below.
\n Multiple options can be appended to forward to directives, separated by
\n whitespaces.
\n? The following options will configure the health-checking method for the
\n table, and is mandatory for redirections:
\n? check http path [host hostname] code number
\n For each host in the table, verify that retrieving the URL path
\n gives the HTTP return code number.? If hostname is specified, it
\n is used as the Host:'' header to query a specific hostname at
\n the target host.
\n? check https path [host hostname] code number
\n This has the same effect as above but wraps the HTTP request in
\n SSL.
\n? check http path [host hostname] digest string
\n For each host in the table, verify that retrieving the URL path
\n produces content whose message digest matches the defined string.
\n The algorithm used is determined by the string length of the
\n digest argument, either SHA1 (40 characters) or MD5 (32 charac-
\n ters).? If hostname is specified, it is used as the<\/code>Host:”
\n header to query a specific hostname at the target host.? The di-
\n gest does not take the HTTP headers into account.?To compute the
\n digest, use this simple command:
\n? $ ftp -o – http:\/\/host[:port]\/path<\/a> | sha1
\n This gives a digest that can be used as-is in a digest statement:
\n? a9993e36476816aba3e25717850c26c9cd0d89d
\n? check https path [host hostname] digest string
\n This has the same effect as above but wraps the HTTP request in
\n SSL.
\n? check icmp
\n Ping hosts in this table to determine whether they are up or not.
\n This method will automatically use ICMP or ICMPV6 depending on
\n the address family of each host.
\n? check script path
\n Execute an external program to check the host state.? The program
\n will be executed for each host by specifing the hostname on the
\n command line:
\n? \/usr\/local\/bin\/checkload.pl front-www1.private.example.com
\n relayd(8) expects a positive return value on success and zero on
\n failure.? Note that the script will be executed with the privi-
\n leges of the “_relayd” user and terminated after timeout mil-
\n liseconds.
\n? check send data expect pattern [ssl]
\n For each host in the table, a TCP connection is established on
\n the port specified, then data is sent.? Incoming data is then
\n read and is expected to match against pattern using shell glob-
\n bing rules.? If data is an empty string or nothing then nothing
\n is sent on the connection and data is immediately read.? This can
\n be useful with protocols that output a banner like SMTP, NNTP,
\n and FTP.? If the ssl keyword is present, the transaction will oc-
\n cur in an SSL tunnel.
\n? check ssl
\n Perform a complete SSL handshake with each host to check their
\n availability.
\n? check tcp
\n Use a simple TCP connect to check that hosts are up.
\n? The following general table options are available:
\n? demote group
\n Enable the per-table carp(4) demotion option.? This will incre-
\n ment the carp demotion counter for the specified interface group
\n if all hosts in the table are down.? For more information on in-
\n terface groups, see the group keyword in ifconfig(8).
\n? interval number
\n Override the global interval and specify one for this table.? It
\n must be a multiple of the global interval.
\n? timeout number
\n Set the timeout in milliseconds for each host that is checked us-
\n ing TCP as the transport.?This will override the global timeout,
\n which is 200 milliseconds by default.
\n? The following options will set the scheduling algoritm to select a host
\n from the specified table:
\n? mode hash
\n Balances the outgoing connections across the active hosts based
\n on the hashed name of the table.? Additional input can be fed in-
\n to the hash by looking at HTTP headers and GET variables; see the
\n PROTOCOLS section below.? This mode is only supported by relays.
\n? mode loadbalance
\n Balances the outgoing connections across the active hosts based
\n on the hashed name of the table, the source and destination ad-
\n dresses, and the corresponding ports.? This mode is only support-
\n ed by relays.
\n? mode roundrobin
\n Distributes the outgoing connections using a round-robin sched-
\n uler through all active hosts.? This is the default mode and will
\n be used if no option has been specified.? This mode is supported
\n by redirections and relays.
\nREDIRECTIONS
\n Redirections represent a pf(4) rdr rule.? They are used for stateful
\n redirections to the hosts in the specified tables.? pf(4) rewrites the
\n target IP addresses and ports of the incoming connections, operating on
\n layer 3.? The configuration directives that are valid in the redirect
\n context are described below:
\n? disable
\n The redirection is initially disabled.? It can be later enabled
\n through relayctl(8).
\n? forward to <table> [port number] options …
\n Specify the tables of target hosts to be used; see the TABLES
\n section above for information about table options.? If the port
\n option is not specified, the port from the listen on directive
\n will be used.? This directive can be specified twice – the second
\n entry will be used as the backup table if all hosts in the main
\n table are down.? At least one entry for the main table is manda-
\n tory.
\n? listen on address port port [interface name]
\n Specify an address and a port to listen on.? pf(4) will redirect
\n incoming connections for the specified target to the hosts in the
\n main or backup table.? The rdr rule can be optionally restricted
\n to a given interface name.
\n? sticky-address
\n This has the same effect as specifying sticky-address for an rdr
\n rule in pf.conf(5).? It will ensure that multiple connections
\n from the same source are mapped to the same redirection address.
\n? tag name
\n Automatically tag packets passing through the pf(4) rdr rule with
\n the name supplied.? This allows simpler filter rules.
\nRELAYS
\n Relays will forward traffic between a client and a target server.?In
\n contrast to redirections and IP forwarding in the network stack, a relay
\n will accept incoming connections from remote clients as a server, open an
\n outgoing connection to a target host, and forward any traffic between the
\n target host and the remote client, operating on layer 7.? A relay is also
\n called an application layer gateway or layer 7 proxy.
\n? The main purpose of a relay is to provide advanced load balancing func-
\n tionality based on specified protocol characteristics, such as HTTP head-
\n ers, to provide SSL acceleration and to allow basic handling of the un-
\n derlying application protocol.
\n? The relay configuration directives are described below:
\n? disable
\n Start the relay but immediately close any accepted connections.
\n? forward to address [port port] [retry number]
\n Specify the address and port of the target host to connect to.
\n If the port option is not specified, the port from the listen on
\n directive will be used.
\n The optional host retry option will be used as a tolerance for
\n failed host connections; the connection will be retried for
\n number more times.
\n? forward to <table> [port port] options …
\n Like the previous directive, but connect to a host from the spec-
\n ified table; see the TABLES section above for information about
\n table options.
\n? forward to nat lookup [retry number]
\n When redirecting connections with an rdr rule in pf.conf(5) to a
\n relay listening on localhost, this directive will look up the re-
\n al destination address of the intended target host, allowing the
\n relay to be run as a transparent proxy.? If an additional forward
\n to directive to a specified address or table is present, it will
\n be used as a backup if the NAT lookup failed.
\n? listen on address [port port] [ssl]
\n Specify the address and port for the relay to listen on.? The re-
\n lay will accept incoming connections to the specified address.
\n If the port option is not specified, the port from the listen on
\n directive will be used.
\n If the ssl keyword is present, the relay will accept connections
\n using the encrypted SSL protocol.?The relay will look up a pri-
\n vate key in \/etc\/ssl\/private\/address.key and a public certificate
\n in \/etc\/ssl\/address.crt, where address is the specified IP ad-
\n dress of the relay to listen on.? See ssl(8) for details about
\n SSL server certificates.
\n? protocol name
\n Use the specified protocol definition for the relay.? The generic
\n TCP protocol options will be used by default; see the PROTOCOLS
\n section below.
\n? timeout seconds
\n Specify the timeout in seconds for accepted sessions.? The de-
\n fault timeout is 600 seconds (10 minutes).
\nPROTOCOLS
\n Protocols are templates defining actions and settings for relays.?They
\n allow setting generic TCP options, SSL settings, and actions specific to
\n the selected application layer protocol.
\n? The protocol directive is available for a number of different application
\n layer protocols.? There is no generic handler for UDP-based protocols be-
\n cause it is a stateless datagram-based protocol which has to look into
\n the application layer protocol to find any possible state information.
\n? dns protocol
\n (UDP) Domain Name System (DNS) protocol.? The requested IDs in
\n the DNS header will be used to match the state.? relayd(8) re-
\n places these IDs with random values to compensate for predictable
\n values generated by some hosts.
\n? http protocol
\n Handle the Hypertext Transfer Protocol (HTTP, or “HTTPS” if en-
\n capsulated in an SSL tunnel).
\n? [tcp] protocol
\n Generic handler for TCP-based protocols.? This is the default.
\n? The available configuration directives are described below:
\n? [direction] [type] action [marked id] [log]
\n Define an action for the selected entity.?The optional log key-
\n word will log the entity name and the value and the optional
\n marked keyword requires that the session has been marked with a
\n given identifier in order to execute the action.? The actions are
\n dependent on the underlying application protocol.
\n? [direction] may be one of:
\n? request
\n Handle the data stream from the client to the relay, like HTTP
\n requests.?This is the default if the direction directive is
\n omitted.
\n? response
\n Handle the data stream from the target host to the relay, like
\n HTTP server replies.
\n? [action] may be one of:
\n? cookie? Look up the entity as a value in the Cookie header when using the
\n http protocol.? This type is only available with the direction
\n request.
\n? header? Look up the entity in the application protocol headers, like HTTP
\n headers in http mode.
\n? path Look up the entity as a value in the URL path when using the http
\n protocol.?This type is only available with the direction
\n request.? The key will match the path of the requested URL with-
\n out the hostname and query and the value will match the complete
\n query, for example:
\n? request path filter “\/index.html”
\n request path filter “foo=bar*” from “\/cgi-bin\/t.cgi”
\n? query Look up the entity as a query variable in the URL when using the
\n http protocol.? This type is only available with the direction
\n request, for example:
\n? # Will match \/cgi-bin\/example.pl?foo=bar&ok=yes
\n request query expect “bar” from “foo”
\n? url? Look up the entity as a URL suffix\/prefix expression consisting
\n of a canonicalized hostname without port or suffix and a path
\n name or prefix when using the http protocol.? This type is only
\n available with the direction request, for example:
\n? request url filter “example.com\/index.html”
\n request url filter “example.com\/test.cgi?val=1”
\n relayd(8) will match the full URL and different possible suf-
\n fix\/prefix combinations by stripping subdomains and path compo-
\n nents (up to 5 levels), and the query string.? For example, the
\n following lookups will be done for
\n http:\/\/www.example.com:81\/1\/2\/3\/4\/5.html?query=yes<\/a>:
\n? www.example.com\/1\/2\/3\/4\/5.html?query=yes
\n www.example.com\/1\/2\/3\/4\/5.html
\n www.example.com\/
\n www.example.com\/1\/
\n www.example.com\/1\/2\/
\n www.example.com\/1\/2\/3\/
\n example.com\/1\/2\/3\/4\/5.html?query=yes
\n example.com\/1\/2\/3\/4\/5.html
\n example.com\/
\n example.com\/1\/
\n example.com\/1\/2\/
\n example.com\/1\/2\/3\/
\n? [action] may be one of:
\n? append value to key
\n Append the specified value to a protocol entity with the selected
\n name.? When using the http protocol, key will indicate a speci-
\n fied HTTP header.?If key does not exist in the request, it will
\n be created with the value set to value.
\n The value string may contain predefined macros that will be ex-
\n panded at runtime:
\n? $REMOTE_ADDR? The IP address of the connected client.
\n $REMOTE_PORT? The TCP source port of the connected client.
\n $SERVER_ADDR? The configured IP address of the relay.
\n $SERVER_PORT? The configured TCP server port of the relay.
\n $TIMEOUT? The configured session timeout of the relay.
\n? change key to value
\n Like the append directive above, but change the contents of the
\n specified entity.?If key does not exist in the request, it will
\n be created with the value set to value.
\n The value string may contain predefined macros that will be ex-
\n panded at runtime, as detailed for the append directive above.
\n? expect value from key
\n Expect an entity key and match against value using shell globbing
\n rules.? If the entity is not present or the value doesn’t match,
\n the connection will be dropped.
\n? expect [digest] key
\n Expect an entity key with any possible value.? This is the short
\n form of expect * from key.
\n If the digest keyword is specified, compare the message digest of
\n the entity against the defined string.? The algorithm used is de-
\n termined by the string length of the key argument, either SHA1
\n (40 characters) or MD5 (32 characters).? To compute the digest,
\n use this simple command:
\n? $ echo -n “example.com\/path\/?args” | sha1
\n? filter value from key
\n Like the expect .. from directive above, but drop any connections
\n with the specified entity key and a matching value.
\n? filter [digest] key
\n Like the expect directive above, but drop any connections with
\n the specified entity key and any possible value.? This is the
\n short form of filter * from key.
\n? hash key
\n Feed the value of the selected entity into the load balancing
\n hash to select the target host.? See the table keyword in the
\n RELAYS section above.
\n? log key
\n Log the name and the value of the entity.
\n? mark [value from] key with id
\n Mark the session with the specified identifier (a positive number
\n between 1 and 65535) if the specified condition matches.? Note
\n that the mark action does not accept the marked option (see
\n above).
\n? label string
\n Add a label to subsequently added actions.? The label will be
\n printed as part of the error message if the return error option
\n is set and may contain HTML tags, for example:
\n? label “<a href=’http:\/\/example.com\/advisory.pl?id=7359<\/a>‘>
\n Advisory provided by example.com<\/a>”
\n url filter digest 5c1e03f58f8ce0b457474ffb371fd1ef
\n url filter digest 80c1a7b8337462093ef8359c57b4d56a
\n no label
\n? no label
\n Do not set a label for subsequently added actions; this is the
\n default.
\n? remove key
\n Remove the entity with the selected name.
\n? return error [option]
\n Return an error reponse to the client if an internal operation or
\n the forward connection to the client failed.? By default, the
\n connection will be silently dropped.? The effect of this option
\n depends on the protocol: HTTP will send an error header and page
\n to the client before closing the connection.? Additional valid
\n options are:
\n style string
\n Specify a Cascading Style Sheet (CSS) to be used for the
\n returned HTTP error pages, for example:
\n body { background: #a00000; color: white; }
\n? ssl option
\n Set the SSL options and session settings.?This is only used if
\n SSL is enabled in the relay.? Valid options are:
\n ciphers string
\n Set the string defining the SSL cipher suite.? If not
\n specified, the default value HIGH:!ADH will be used
\n (strong crypto cipher suites without anonymous DH).? See
\n the CIPHERS section of openssl(1) for information about
\n SSL cipher suites and preference lists.
\n session cache value
\n Set the maximum size of the SSL session cache.? If the
\n value is zero, the default size defined by the SSL li-
\n brary will be used.? A positive number will set the maxi-
\n mum size in bytes and the keyword disable will disable
\n the SSL session cache.
\n [no] sslv2
\n Enable the SSLv2 protocol; disabled by default.
\n [no] sslv3
\n Disable the SSLv3 protocol; enabled by default.
\n [no] tlsv1
\n Disable the TLSv1\/SSLv3.1 protocol; enabled by default.
\n? tcp option
\n Enable or disable the specified TCP\/IP options; see tcp(4) and
\n ip(4) for more information about the options.? Valid options are:
\n backlog number
\n Set the maximum length the queue of pending connections
\n may grow to.? The backlog option is 10 by default and is
\n limited by the kern.somaxconn sysctl(8) variable.
\n ip minttl number
\n This option for the underlying IP connection may be used
\n to discard packets with a TTL lower than the specified
\n value.? This can be used to implement the Generalized TTL
\n Security Mechanism (GTSM) according to RFC 3682.
\n ip ttl? Change the default time-to-live value in the IP headers.
\n [no] nodelay
\n Enable the TCP NODELAY option for this connection.? This
\n is recommended to avoid delays in the relayed data
\n stream, e.g. for SSH connections.
\n [no] sack
\n Use selective acknowledgements for this connection.
\n socket buffer number
\n Set the socket-level buffer size for input and output for
\n this connection.? This will affect the TCP window size.
\nFILES
\n \/etc\/relayd.conf relayd(8) configuration file.
\n? \/etc\/services Service name database.
\n? \/etc\/ssl\/address.crt
\n \/etc\/ssl\/private\/address.key Location of the relay SSL server certifi-
\n cates, where address is the configured IP
\n address of the relay.
\nEXAMPLES
\n This configuration file would create a service www'' which load bal-
\n ances four hosts and falls back to one host containing a<\/code>sorry page”:
\n www1=front-www1.private.example.com
\n www2=front-www2.private.example.com
\n www3=front-www3.private.example.com
\n www4=front-www4.private.example.com
\n interval 5
\n table <phphosts> { $www1, $www2, $www3, $www4 }
\n table <sorryhost> disable { sorryhost.private.example.com }
\n redirect “www” {
\n listen on www.example.com port 8080 interface trunk0
\n listen on www6.example.com port 80 interface trunk0
\n? tag REDIRECTED
\n? forward to <phphosts> port 8080 timeout 300
\n check http “\/” digest “630aa3c2f…”
\n forward to <sorryhost> port 8080 timeout 300 check icmp
\n }
\n? The following configuration would add a relay to forward secure HTTPS
\n connections to a pool of HTTP webservers using the loadbalance mode (SSL
\n acceleration and layer 7 load balancing).?The HTTP protocol definition
\n will add two HTTP headers containing address information of the client
\n and the server, set the Keep-Alive'' header value to the configured
\n session timeout, and include the<\/code>sessid” variable in the hash to cal-
\n culate the target host:
\n http protocol “http_ssl” {
\n header append “$REMOTE_ADDR” to “X-Forwarded-For”
\n header append “$SERVER_ADDR:$SERVER_PORT” to “X-Forwarded-By”
\n header change “Keep-Alive” to “$TIMEOUT”
\n query hash “sessid”
\n cookie hash “sessid”
\n path filter “*command=*” from “\/cgi-bin\/index.cgi”
\n? ssl { sslv2, ciphers “MEDIUM:HIGH” }
\n }
\n relay “sslaccel” {
\n listen on www.example.com port 443 ssl
\n protocol “http_ssl”
\n forward to <phphosts> port 8080 mode loadbalance check tcp
\n }
\n? The second relay example will accept incoming connections to port 2222
\n and forward them to a remote SSH server.? The TCP nodelay option will al-
\n low a “smooth” SSH session without delays between keystrokes or dis-
\n played output on the terminal:
\n protocol “myssh” {
\n tcp { nodelay, socket buffer 65536 }
\n }
\n relay “sshforward” {
\n listen on www.example.com port 2222
\n protocol “myssh”
\n forward to shell.example.com port 22
\n }
\nSEE ALSO
\n relayctl(8), relayd(8), snmpd(8), ssl(8)
\nHISTORY
\n The relayd.conf file format, formerly known as hoststated.conf, first ap-
\n peared in OpenBSD 4.1.? It was renamed to relayd.conf in OpenBSD 4.3.
\nAUTHORS
\n The relayd(8) program was written by Pierre-Yves Ritschard
\n <pyr@openbsd.org> and Reyk Floeter <reyk@openbsd.org>.
\nOpenBSD 4.3 March 3, 2008? 11<\/p>\n

\u8f6c\u8f7d\u8bf7\u6ce8\u660e\uff1aKermit\u7684\u7f51\u7ad9<\/a> » RELAYD.CONF<\/a><\/p>","protected":false},"excerpt":{"rendered":"

RELAYD.CONF(5) OpenBSD Programmer’s ManualRELAYD.CONF(5) http:\/\/www.openbsd.org\/cgi-bin\/man.cgi?query=relayd.conf&s […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-21","post","type-post","status-publish","format-standard","hentry","category-technology"],"_links":{"self":[{"href":"https:\/\/www.houquner.com\/index.php\/wp-json\/wp\/v2\/posts\/21"}],"collection":[{"href":"https:\/\/www.houquner.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.houquner.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.houquner.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.houquner.com\/index.php\/wp-json\/wp\/v2\/comments?post=21"}],"version-history":[{"count":0,"href":"https:\/\/www.houquner.com\/index.php\/wp-json\/wp\/v2\/posts\/21\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.houquner.com\/index.php\/wp-json\/wp\/v2\/media?parent=21"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.houquner.com\/index.php\/wp-json\/wp\/v2\/categories?post=21"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.houquner.com\/index.php\/wp-json\/wp\/v2\/tags?post=21"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}