What is section.io’s Edge Proxy?
Every section.io application proxy stack implicitly begins with the Edge proxy. The Edge proxy is the endpoint to which the User-Agent (eg web browser) connects and it has a few responsibilities:
- Performing the TLS handshake for HTTPS connections
- Routing requests to the corresponding application proxy stack
- Implementing the HTTP/2 protocol
- Request correlation
- Serving custom error pages
This enables a consistent experience on the section.io platform regardless of which proxies are in your application’s stack or in which sequence they appear.
For each incoming request, the Edge proxy attempts to resolve the client’s connecting IP address to a geographic location. The results of the lookup are then exposed to the other proxies in the proxy stack and to the origin web server as HTTP request headers. These headers are:
section-io-geo-country-code- the ISO 3166-1 alpha-2 country code such as
USfor the United States, or
section-io-geo-country-name- the country name such as
section-io-geo-region-code- examples include
VAfor US IPs or
NSWfor Australian IPs.
section-io-geo-region-name- examples include
Virginiafor US IPs or
New South Walesfor Australian IPs.
section-io-geo-city- examples include
section-io-geo-latlon- the approximate latitude and longitude in the format
section-io-geo-postal-code- examples include
2047for Drummoyne, NSW, Australia and
80302for Boulder, CO, USA.
section-io-geo-dma-code- The Nielsen Designated Market Area ID as used by DoubleClick. Only for US IPs.
Not all headers are populated for all IP addresses.
The latitude, longitude, country code, and city values are also available in the access logs.
Client IP Detection
For each request the edge proxy will also add a
True-Client-IP request header which provides the IP address of the client that connected to us. This is the same IP address used for the IP geolocation.
This request header can be used in a number of ways:
- Fraud detection
- IP Whitelist/Blacklisting, including restricting access to particular urls.
- Logging client usage
- Rate limiting
section.io also sets the
X-Forwarded-For header if you need to use that, however this header will often be a list of IP addresses depending on how the request has been proxied prior to arriving at section.io and is not always reliable.
When the Edge proxy handles each incoming request, a unique identifier is generated and is added to the request via a
section-io-id HTTP request header.
This request header then propagates through to each proxy in your application’s proxy stack and ultimately to your application’s configured origin web server. When the final response is returned from your application, via the proxy stack, to the User-Agent, the Edge proxy also inserts the same identifier as a
section-io-id HTTP response header.
section-io-id value is available in all the proxy logs provided by Aperture to enable easy correlation of log entries across the different proxies in the stack. You can also choose to log the
section-io-id request header on your origin server to aid with diagnostics.
By providing the identifier as a request header, its value can be consumed in your chosen proxies. For example, Varnish can refer to
req.http.section-io-id in the VCL.
The format of the
section-io-id identifier is subject to change without notice so it should be treated as an opaque string and no meaning should be inferred from its value.