Unit Instance

HTTP 200 OK
Allow: GET, PUT, PATCH, DELETE, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesfiltering-bridges_index/nb_NO/?format=api",
    "source": [
        "New in FreeBSD 4.0, is the concept of stateful filtering.  This is a big improvement for UDP traffic, which typically is a request going out, followed shortly thereafter by a response with the same set of IP addresses and port numbers (but with source and destination reversed, of course).  For firewalls that have no statekeeping, there is almost no way to deal with this sort of traffic as a single session.  But with a firewall that can \"remember\" an outgoing UDP packet and, for the next few minutes, allow a response, handling UDP services is trivial.  The following example shows how to do it.  It is possible to do the same thing with TCP packets.  This allows you to avoid some denial of service attacks and other nasty tricks, but it also typically makes your state table grow quickly in size."
    ],
    "previous_source": "",
    "target": [
        ""
    ],
    "id_hash": -954341307957279448,
    "content_hash": -954341307957279448,
    "location": "documentation/content/en/articles/filtering-bridges/_index.adoc:185",
    "context": "",
    "note": "type: Plain text",
    "flags": "",
    "labels": [],
    "state": 0,
    "fuzzy": false,
    "translated": false,
    "approved": false,
    "position": 38,
    "has_suggestion": false,
    "has_comment": false,
    "has_failing_check": false,
    "num_words": 141,
    "source_unit": "https://translate-dev.freebsd.org/api/units/1615920/?format=api",
    "priority": 100,
    "id": 1615928,
    "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesfiltering-bridges_index/nb_NO/?checksum=72c17fa300b98528",
    "url": "https://translate-dev.freebsd.org/api/units/1615928/?format=api",
    "explanation": "",
    "extra_flags": "",
    "pending": false,
    "timestamp": "2024-01-18T00:33:08.169067Z"
}