Skip to content
Kong Docs are moving soon! Our docs are migrating to a new home. You'll be automatically redirected to the new site in the future. In the meantime, view this page on the new site!
Kong Logo | Kong Docs Logo
  • Docs
    • Explore the API Specs
      View all API Specs View all API Specs View all API Specs arrow image
    • Documentation
      API Specs
      Kong Gateway
      Lightweight, fast, and flexible cloud-native API gateway
      Kong Konnect
      Single platform for SaaS end-to-end connectivity
      Kong AI Gateway
      Multi-LLM AI Gateway for GenAI infrastructure
      Kong Mesh
      Enterprise service mesh based on Kuma and Envoy
      decK
      Helps manage Kong’s configuration in a declarative fashion
      Kong Ingress Controller
      Works inside a Kubernetes cluster and configures Kong to proxy traffic
      Kong Gateway Operator
      Manage your Kong deployments on Kubernetes using YAML Manifests
      Insomnia
      Collaborative API development platform
  • Plugin Hub
    • Explore the Plugin Hub
      View all plugins View all plugins View all plugins arrow image
    • Functionality View all View all arrow image
      View all plugins
      AI's icon
      AI
      Govern, secure, and control AI traffic with multi-LLM AI Gateway plugins
      Authentication's icon
      Authentication
      Protect your services with an authentication layer
      Security's icon
      Security
      Protect your services with additional security layer
      Traffic Control's icon
      Traffic Control
      Manage, throttle and restrict inbound and outbound API traffic
      Serverless's icon
      Serverless
      Invoke serverless functions in combination with other plugins
      Analytics & Monitoring's icon
      Analytics & Monitoring
      Visualize, inspect and monitor APIs and microservices traffic
      Transformations's icon
      Transformations
      Transform request and responses on the fly on Kong
      Logging's icon
      Logging
      Log request and response data using the best transport for your infrastructure
  • Support
  • Community
  • Kong Academy
Get a Demo Start Free Trial
Kong Gateway
3.10.x (latest)
  • Home icon
  • Kong Gateway
  • Plugin Development
  • PDK
  • kong.response
github-edit-pageEdit this page
report-issueReport an issue
  • Kong Gateway
  • Kong Konnect
  • Kong Mesh
  • Kong AI Gateway
  • Plugin Hub
  • decK
  • Kong Ingress Controller
  • Kong Gateway Operator
  • Insomnia
  • Kuma

  • Docs contribution guidelines
  • 3.10.x (latest)
  • 3.9.x
  • 3.8.x
  • 3.7.x
  • 3.6.x
  • 3.5.x
  • 3.4.x (LTS)
  • 3.3.x
  • 2.8.x (LTS)
  • Archive (3.0.x and pre-2.8.x)
  • Introduction
    • Overview of Kong Gateway
    • Support
      • Version Support Policy
      • Third Party Dependencies
      • Browser Support
      • Vulnerability Patching Process
      • Software Bill of Materials
    • Stability
    • Release Notes
    • Breaking Changes
      • Kong Gateway 3.10.x
      • Kong Gateway 3.9.x
      • Kong Gateway 3.8.x
      • Kong Gateway 3.7.x
      • Kong Gateway 3.6.x
      • Kong Gateway 3.5.x
      • Kong Gateway 3.4.x
      • Kong Gateway 3.3.x
      • Kong Gateway 3.2.x
      • Kong Gateway 3.1.x
      • Kong Gateway 3.0.x
      • Kong Gateway 2.8.x or earlier
    • Key Concepts
      • Services
      • Routes
      • Consumers
      • Upstreams
      • Plugins
      • Consumer Groups
    • How Kong Works
      • Routing Traffic
      • Load Balancing
      • Health Checks and Circuit Breakers
    • Glossary
  • Get Started with Kong
    • Get Kong
    • Services and Routes
    • Rate Limiting
    • Proxy Caching
    • Key Authentication
    • Load-Balancing
  • Install Kong
    • Overview
    • Kubernetes
      • Overview
      • Install Kong Gateway
      • Configure the Admin API
      • Install Kong Manager
    • Docker
      • Using docker run
      • Build your own Docker images
    • Linux
      • Amazon Linux
      • Debian
      • Red Hat
      • Ubuntu
    • Post-installation
      • Set up a data store
      • Apply Enterprise license
      • Enable Kong Manager
  • Kong in Production
    • Deployment Topologies
      • Overview
      • Kubernetes Topologies
      • Hybrid Mode
        • Overview
        • Deploy Kong Gateway in Hybrid mode
        • Incremental Configuration Sync
      • DB-less Deployment
      • Traditional
    • Running Kong
      • Running Kong as a non-root user
      • Securing the Admin API
      • Using systemd
    • Access Control
      • Start Kong Gateway Securely
      • Programatically Creating Admins
      • Enabling RBAC
      • Workspaces
    • Licenses
      • Overview
      • Download your License
      • Deploy Enterprise License
      • Using the License API
      • Monitor Licenses Usage
    • Networking
      • Default Ports
      • DNS Considerations
      • Network and Firewall
      • CP/DP Communication through a Forward Proxy
      • PostgreSQL TLS
        • Configure PostgreSQL TLS
        • Troubleshooting PostgreSQL TLS
    • Kong Configuration File
    • Environment Variables
    • Serving a Website and APIs from Kong
    • Secrets Management
      • Overview
      • Getting Started
      • Secrets Rotation
      • Advanced Usage
      • Backends
        • Overview
        • Environment Variables
        • AWS Secrets Manager
        • Azure Key Vaults
        • Google Cloud Secret Manager
        • HashiCorp Vault
      • How-To
        • Securing the Database with AWS Secrets Manager
      • Reference Format
    • Keyring and Data Encryption
    • Monitoring
      • Overview
      • Prometheus
      • StatsD
      • Datadog
      • Health Check Probes
      • Expose and graph AI Metrics
    • Tracing
      • Overview
      • Writing a Custom Trace Exporter
      • Tracing API Reference
    • Resource Sizing Guidelines
    • Blue-Green Deployments
    • Canary Deployments
    • Clustering Reference
    • Performance
      • Performance Testing Benchmarks
      • Establish a Performance Benchmark
      • Improve performance with Brotli compression
    • Logging and Debugging
      • Log Reference
      • Dynamic log level updates
      • Customize Gateway Logs
      • Debug Requests
      • AI Gateway Analytics
      • Audit Logging
    • Configure a gRPC service
    • Use the Expressions Router
    • Outage Handling
      • Configure Data Plane Resilience
      • About Control Plane Outage Management
    • Upgrade and Migration
      • Upgrading Kong Gateway 3.x.x
      • Backup and Restore
      • Upgrade Strategies
        • Dual-Cluster Upgrade
        • In-Place Upgrade
        • Blue-Green Upgrade
        • Rolling Upgrade
      • Upgrade from 2.8 LTS to 3.4 LTS
      • Migrate from OSS to Enterprise
      • Migration Guidelines Cassandra to PostgreSQL
      • Migrate to the new DNS client
      • Breaking Changes
    • FIPS 140-2
      • Overview
      • Install the FIPS Compliant Package
    • Authenticate your Kong Gateway Amazon RDS database with AWS IAM
    • Verify Signatures for Signed Kong Images
    • Verify Build Provenance for Signed Kong Images
  • Kong AI Gateway
    • Overview
    • Get started with AI Gateway
    • LLM Provider Integration Guides
      • OpenAI
      • Cohere
      • Azure
      • Anthropic
      • Mistral
      • Llama2
      • Vertex/Gemini
      • Amazon Bedrock
    • LLM Library Integration Guides
      • LangChain
    • AI Gateway Analytics
    • Expose and graph AI Metrics
    • AI Gateway Load Balancing
    • AI Gateway plugins
  • Kong Manager
    • Overview
    • Enable Kong Manager
    • Get Started with Kong Manager
      • Services and Routes
      • Rate Limiting
      • Proxy Caching
      • Authentication with Consumers
      • Load Balancing
    • Authentication and Authorization
      • Overview
      • Create a Super Admin
      • Workspaces and Teams
      • Reset Passwords and RBAC Tokens
      • Basic Auth
      • LDAP
        • Configure LDAP
        • LDAP Service Directory Mapping
      • OIDC
        • Configure OIDC
        • OIDC Authenticated Group Mapping
        • Migrate from previous configurations
      • Sessions
      • RBAC
        • Overview
        • Enable RBAC
        • Add a Role and Permissions
        • Create a User
        • Create an Admin
    • Networking Configuration
    • Workspaces
    • Create Consumer Groups
    • Sending Email
    • Troubleshoot
    • Strengthen Security
  • Develop Custom Plugins
    • Overview
    • Getting Started
      • Introduction
      • Set up the Plugin Project
      • Add Plugin Testing
      • Add Plugin Configuration
      • Consume External Services
      • Deploy Plugins
    • File Structure
    • Implementing Custom Logic
    • Plugin Configuration
    • Accessing the Data Store
    • Storing Custom Entities
    • Caching Custom Entities
    • Extending the Admin API
    • Writing Tests
    • Installation and Distribution
    • Proxy-Wasm Filters
      • Create a Proxy-Wasm Filter
      • Proxy-Wasm Filter Configuration
    • Plugin Development Kit
      • Overview
      • kong.client
      • kong.client.tls
      • kong.cluster
      • kong.ctx
      • kong.ip
      • kong.jwe
      • kong.log
      • kong.nginx
      • kong.node
      • kong.plugin
      • kong.request
      • kong.response
      • kong.router
      • kong.service
      • kong.service.request
      • kong.service.response
      • kong.table
      • kong.telemetry.log
      • kong.tracing
      • kong.vault
      • kong.websocket.client
      • kong.websocket.upstream
    • Plugins in Other Languages
      • Go
      • Javascript
      • Python
      • Running Plugins in Containers
      • External Plugin Performance
  • Kong Plugins
    • Overview
    • Authentication Reference
    • Allow Multiple Authentication Plugins
    • Plugin Queuing
      • Overview
      • Plugin Queuing Reference
    • Dynamic Plugin Ordering
      • Overview
      • Get Started with Dynamic Plugin Ordering
    • Redis Partials
    • Datakit
      • Overview
      • Get Started with Datakit
      • Datakit Configuration Reference
      • Datakit Examples Reference
  • Admin API
    • Overview
    • Declarative Configuration
    • Enterprise API
      • Information Routes
      • Health Routes
      • Tags
      • Debug Routes
      • Services
      • Routes
      • Consumers
      • Plugins
      • Certificates
      • CA Certificates
      • SNIs
      • Upstreams
      • Targets
      • Vaults
      • Keys
      • Filter Chains
      • Licenses
      • Workspaces
      • RBAC
      • Admins
      • Consumer Groups
      • Event Hooks
      • Keyring and Data Encryption
      • Audit Logs
      • Status API
  • Reference
    • kong.conf
    • Injecting Nginx Directives
    • CLI
    • Key Management
    • The Expressions Language
      • Overview
      • Language References
      • Performance Optimizations
    • Rate Limiting Library
    • WebAssembly
    • Event Hooks
    • FAQ
On this pageOn this page
  • kong.response.get_status()
  • kong.response.get_header(name)
  • kong.response.get_headers([max_headers])
  • kong.response.get_source()
  • kong.response.set_status(status)
  • kong.response.set_header(name, of)
  • kong.response.add_header(name, value)
  • kong.response.clear_header(name)
  • kong.response.set_headers(headers)
  • kong.response.get_raw_body()
  • kong.response.set_raw_body(body)
  • kong.response.exit(status[, body[, headers]])
  • kong.response.error(status[, message[, headers]])

kong.response

Client response module.

The downstream response module contains a set of functions for producing and manipulating responses sent back to the client (downstream). Responses can be produced by Kong (for example, an authentication plugin rejecting a request), or proxied back from an Service’s response body.

Unlike kong.service.response, this module allows mutating the response before sending it back to the client.

kong.response.get_status()

Returns the HTTP status code currently set for the downstream response (as a Lua number).

If the request was proxied (as per kong.response.get_source()), the return value is the response from the Service (identical to kong.service.response.get_status()).

If the request was not proxied and the response was produced by Kong itself (i.e. via kong.response.exit()), the return value is returned as-is.

Phases

  • header_filter, response, body_filter, log, admin_api

Returns

  • number: status The HTTP status code currently set for the downstream response.

Usage

kong.response.get_status() -- 200

kong.response.get_header(name)

Returns the value of the specified response header, as would be seen by the client once received.

The list of headers returned by this function can consist of both response headers from the proxied Service and headers added by Kong (e.g. via kong.response.add_header()).

The return value is either a string, or can be nil if a header with name is not found in the response. If a header with the same name is present multiple times in the request, this function returns the value of the first occurrence of this header.

Phases

  • header_filter, response, body_filter, log, admin_api

Parameters

  • name (string): The name of the header.

Header names are case-insensitive and dashes (-) can be written as underscores (_). For example, the header X-Custom-Header can also be retrieved as x_custom_header.

Returns

  • string|nil: The value of the header.

Usage

-- Given a response with the following headers:
-- X-Custom-Header: bla
-- X-Another: foo bar
-- X-Another: baz

kong.response.get_header("x-custom-header") -- "bla"
kong.response.get_header("X-Another")       -- "foo bar"
kong.response.get_header("X-None")          -- nil

kong.response.get_headers([max_headers])

Returns a Lua table holding the response headers. Keys are header names. Values are either a string with the header value, or an array of strings if a header was sent multiple times. Header names in this table are case-insensitive and are normalized to lowercase, and dashes (-) can be written as underscores (_). For example, the header X-Custom-Header can also be retrieved as x_custom_header.

A response initially has no headers. Headers are added when a plugin short-circuits the proxying by producing a header (e.g. an authentication plugin rejecting a request), or if the request has been proxied, and one of the latter execution phases is currently running.

Unlike kong.service.response.get_headers(), this function returns all headers as the client would see them upon reception, including headers added by Kong itself.

By default, this function returns up to 100 headers (or what has been configured using lua_max_resp_headers). The optional max_headers argument can be specified to customize this limit, but must be greater than 1 and equal to or less than 1000.

Phases

  • header_filter, response, body_filter, log, admin_api

Parameters

  • max_headers (number, optional): Limits the number of headers parsed.

Returns

  1. table: headers A table representation of the headers in the response.

  2. string: err If more headers than max_headers were present, returns a string with the error "truncated".

Usage

-- Given an response from the Service with the following headers:
-- X-Custom-Header: bla
-- X-Another: foo bar
-- X-Another: baz

local headers = kong.response.get_headers()

headers.x_custom_header -- "bla"
headers.x_another[1]    -- "foo bar"
headers["X-Another"][2] -- "baz"

kong.response.get_source()

This function helps determine where the current response originated from. Since Kong is a reverse proxy, it can short-circuit a request and produce a response of its own, or the response can come from the proxied Service.

Returns a string with three possible values:

  • "exit" is returned when, at some point during the processing of the request, there has been a call to kong.response.exit(). This happens when the request was short-circuited by a plugin or by Kong itself (e.g. invalid credentials).
  • "error" is returned when an error has happened while processing the request. For example, a timeout while connecting to the upstream service.
  • "service" is returned when the response was originated by successfully contacting the proxied Service.

Phases

  • header_filter, response, body_filter, log, admin_api

Returns

  • string: The source.

Usage

if kong.response.get_source() == "service" then
  kong.log("The response comes from the Service")
elseif kong.response.get_source() == "error" then
  kong.log("There was an error while processing the request")
elseif kong.response.get_source() == "exit" then
  kong.log("There was an early exit while processing the request")
end

kong.response.set_status(status)

Allows changing the downstream response HTTP status code before sending it to the client.

Phases

  • rewrite, access, header_filter, response, admin_api

Parameters

  • status (number): The new status.

Returns

  • Nothing; throws an error on invalid input.

Usage

kong.response.set_status(404)

kong.response.set_header(name, of)

Sets a response header with the given value. This function overrides any existing header with the same name.

Note: Underscores in header names are automatically transformed into dashes by default. If you want to deactivate this behavior, set the lua_transform_underscores_in_response_headers Nginx config option to off.

This setting can be set in the Kong Config file:

 nginx_http_lua_transform_underscores_in_response_headers = off

Be aware that changing this setting might break any plugins that rely on the automatic underscore conversion. You cannot set Transfer-Encoding header with this function. It will be ignored.

Phases

  • rewrite, access, header_filter, response, admin_api

Parameters

  • name (string): The name of the header
  • value (array of strings|string|number|boolean): The new value for the header.

  • of (array of strings|string|number|boolean): The new value for the header.

Returns

  • Nothing; throws an error on invalid input.

Usage

kong.response.set_header("X-Foo", "value")

kong.response.add_header(name, value)

Adds a response header with the given value. Unlike kong.response.set_header(), this function does not remove any existing header with the same name. Instead, another header with the same name is added to the response. If no header with this name already exists on the response, then it is added with the given value, similarly to kong.response.set_header().

Phases

  • rewrite, access, header_filter, response, admin_api

Parameters

  • name (string): The header name.
  • value (array of strings|string|number|boolean): The header value.

Returns

  • Nothing; throws an error on invalid input.

Usage

kong.response.add_header("Cache-Control", "no-cache")
kong.response.add_header("Cache-Control", "no-store")

kong.response.clear_header(name)

Removes all occurrences of the specified header in the response sent to the client.

Phases

  • rewrite, access, header_filter, response, admin_api

Parameters

  • name (string): The name of the header to be cleared

Returns

  • Nothing; throws an error on invalid input.

Usage

kong.response.set_header("X-Foo", "foo")
kong.response.add_header("X-Foo", "bar")

kong.response.clear_header("X-Foo")
-- from here onwards, no X-Foo headers will exist in the response

kong.response.set_headers(headers)

Sets the headers for the response. Unlike kong.response.set_header(), the headers argument must be a table in which each key is a string corresponding to a header’s name, and each value is a string, or an array of strings.

The resulting headers are produced in lexicographical order. The order of entries with the same name (when values are given as an array) is retained.

This function overrides any existing header bearing the same name as those specified in the headers argument. Other headers remain unchanged.

You cannot set Transfer-Encoding header with this function. It will be ignored.

Phases

  • rewrite, access, header_filter, response, admin_api

Parameters

  • headers (table):

Returns

  • Nothing; throws an error on invalid input.

Usage

kong.response.set_headers({
  ["Bla"] = "boo",
  ["X-Foo"] = "foo3",
  ["Cache-Control"] = { "no-store", "no-cache" }
})

-- Will add the following headers to the response, in this order:
-- X-Bar: bar1
-- Bla: boo
-- Cache-Control: no-store
-- Cache-Control: no-cache
-- X-Foo: foo3

kong.response.get_raw_body()

Returns the full body when the last chunk has been read.

Calling this function starts buffering the body in an internal request context variable, and sets the current chunk (ngx.arg[1]) to nil when the chunk is not the last one. When it reads the last chunk, the function returns the full buffered body.

Phases

  • body_filter

Returns

  • string: body The full body when the last chunk has been read, otherwise returns nil.

Usage

local body = kong.response.get_raw_body()
if body then
  body = transform(body)
  kong.response.set_raw_body(body)
end

kong.response.set_raw_body(body)

Sets the body of the response.

The body argument must be a string and is not processed in any way. This function can’t change the Content-Length header if one was added. If you decide to use this function, the Content-Length header should also be cleared, for example in the header_filter phase.

Phases

  • body_filter

Parameters

  • body (string): The raw body.

Returns

  • Nothing; throws an error on invalid inputs.

Usage

kong.response.set_raw_body("Hello, world!")
-- or
local body = kong.response.get_raw_body()
if body then
  body = transform(body)
  kong.response.set_raw_body(body)
end

kong.response.exit(status[, body[, headers]])

This function interrupts the current processing and produces a response. It is typical to see plugins using it to produce a response before Kong has a chance to proxy the request (e.g. an authentication plugin rejecting a request, or a caching plugin serving a cached response).

It is recommended to use this function in conjunction with the return operator, to better reflect its meaning:

 return kong.response.exit(200, "Success")

Calling kong.response.exit() interrupts the execution flow of plugins in the current phase. Subsequent phases will still be invoked. For example, if a plugin calls kong.response.exit() in the access phase, no other plugin is executed in that phase, but the header_filter, body_filter, and log phases are still executed, along with their plugins. Plugins should be programmed defensively against cases when a request is not proxied to the Service, but instead is produced by Kong itself.

  1. The first argument status sets the status code of the response that is seen by the client.

    In L4 proxy mode, the status code provided is primarily for logging and statistical purposes, and is not visible to the client directly. In this mode, only the following status codes are supported:

    • 200 - OK
    • 400 - Bad request
    • 403 - Forbidden
    • 500 - Internal server error
    • 502 - Bad gateway
    • 503 - Service unavailable
  2. The second, optional, body argument sets the response body. If it is a string, no special processing is done, and the body is sent as-is. It is the caller’s responsibility to set the appropriate Content-Type header via the third argument.

    As a convenience, body can be specified as a table. In that case, the body is JSON-encoded and has the application/json Content-Type header set.

    On gRPC, we cannot send the body with this function, so it sends "body" in the grpc-message header instead.

    • If the body is a table, it looks for the message field in the body, and uses that as a grpc-message header.
    • If you specify application/grpc in the Content-Type header, the body is sent without needing the grpc-message header.

    In L4 proxy mode, body can only be nil or a string. Automatic JSON encoding is not available. When body is provided, depending on the value of status, the following happens:

    • When status is 500, 502 or 503, then body is logged in the Kong error log file.
    • When the status is anything else, body is sent back to the L4 client.
  3. The third, optional, headers argument can be a table specifying response headers to send. If specified, its behavior is similar to kong.response.set_headers(). This argument is ignored in L4 proxy mode.

Unless manually specified, this method automatically sets the Content-Length header in the produced response for convenience.

Phases

  • preread, rewrite, access, admin_api, header_filter (only if body is nil)

Parameters

  • status (number): The status to be used.
  • body (table|string, optional): The body to be used.
  • headers (table, optional): The headers to be used.

Returns

  • Nothing; throws an error on invalid input.

Usage

return kong.response.exit(403, "Access Forbidden", {
  ["Content-Type"] = "text/plain",
  ["WWW-Authenticate"] = "Basic"
})

---

return kong.response.exit(403, [[{"message":"Access Forbidden"}]], {
  ["Content-Type"] = "application/json",
  ["WWW-Authenticate"] = "Basic"
})

---

return kong.response.exit(403, { message = "Access Forbidden" }, {
  ["WWW-Authenticate"] = "Basic"
})

---

-- In L4 proxy mode
return kong.response.exit(200, "Success")

kong.response.error(status[, message[, headers]])

This function interrupts the current processing and produces an error response.

It is recommended to use this function in conjunction with the return operator, to better reflect its meaning:

 return kong.response.error(500, "Error", {["Content-Type"] = "text/html"})
  1. The status argument sets the status code of the response that is seen by the client. The status code must an error code, that is, greater than 399.

  2. The optional message argument sets the message describing the error, which is written in the body.

  3. The optional headers argument can be a table specifying response headers to send. If specified, its behavior is similar to kong.response.set_headers().

This method sends the response formatted in JSON, XML, HTML or plaintext. The actual format is determined using one of the following options, in this order:

  • Manually specified in the headers argument using the Content-Type header.
  • Conforming to the Accept header from the request.
  • If there is no setting in the Content-Type or Accept header, the response defaults to JSON format. Also see the Content-Length header in the produced response for convenience.

Phases

  • rewrite, access, admin_api, header_filter (only if body is nil)

Parameters

  • status (number): The status to be used (>399).
  • message (string, optional): The error message to be used.
  • headers (table, optional): The headers to be used.

Returns

  • Nothing; throws an error on invalid input.

Usage

return kong.response.error(403, "Access Forbidden", {
  ["Content-Type"] = "text/plain",
  ["WWW-Authenticate"] = "Basic"
})

---

return kong.response.error(403, "Access Forbidden")

---

return kong.response.error(403)
Thank you for your feedback.
Was this page useful?
Too much on your plate? close cta icon
More features, less infrastructure with Kong Konnect. 1M requests per month for free.
Try it for Free
  • Kong
    Powering the API world

    Increase developer productivity, security, and performance at scale with the unified platform for API management, service mesh, and ingress controller.

    • Products
      • Kong Konnect
      • Kong Gateway Enterprise
      • Kong Gateway
      • Kong Mesh
      • Kong Ingress Controller
      • Kong Insomnia
      • Product Updates
      • Get Started
    • Documentation
      • Kong Konnect Docs
      • Kong Gateway Docs
      • Kong Mesh Docs
      • Kong Insomnia Docs
      • Kong Konnect Plugin Hub
    • Open Source
      • Kong Gateway
      • Kuma
      • Insomnia
      • Kong Community
    • Company
      • About Kong
      • Customers
      • Careers
      • Press
      • Events
      • Contact
  • Terms• Privacy• Trust and Compliance
© Kong Inc. 2025