redirection_io.md

C@E integration getting started

Follow the documentation to set up your redirection.io account and install the tools to get started with Compute@Edge.

Documents:

• Fastly Compute@Edge integration (redirection.io)
• Compute@Edge getting started

---

Once Fatly CLI and Rust tool chains are configured and installed, clone the agent code.

git clone https://github.com/redirectionio/fastly-worker
cd fastly-worker

Create a fastly.toml in the root directory of your project and copy the following. Then:

• Copy the token from the redirection.io dashboard and paste it in two places
• Change httpbin.org to the domain of the origin server you wish to test

# This file describes a Fastly Compute@Edge package. To learn more visit:
# https://developer.fastly.com/reference/fastly-toml/

authors = ["hkakehashi@fastly.com"]
description = "redirection.io worker"
language = "rust"
manifest_version = 2
name = "fastly-worker"
service_id = ""

[local_server]
  [local_server.backends]
    [local_server.backends.backend_host]
      override_host = "httpbin.org"
      url = "http://httpbin.org/"
    [local_server.backends.redirectionio]
      url = "https://agent.redirection.io"
  [local_server.dictionaries]
    [local_server.dictionaries.redirectionio]
      format = "inline-toml"
      [local_server.dictionaries.redirectionio.contents]
        add_rule_ids_header = "true"
        backend_name = "backend_host"
        instance_name = "Fastly worker"
        token = ""

[setup]
  [setup.backends]
    [setup.backends.backend_host]
      address = "httpbin.org"
      port = 443
    [setup.backends.redirectionio]
      address = "agent.redirection.io"
      port = 443
  [setup.dictionaries]
    [setup.dictionaries.redirectionio]
      [setup.dictionaries.redirectionio.items]
        [setup.dictionaries.redirectionio.items.add_rule_ids_header]
          value = "true"
        [setup.dictionaries.redirectionio.items.backend_name]
          value = "backend_host"
        [setup.dictionaries.redirectionio.items.instance_name]
          value = "Fastly worker"
        [setup.dictionaries.redirectionio.items.token]
          value = ""

[scripts]
  build = "cargo build --bin redirectionio-fastly-worker --release --target wasm32-wasi --color always"

To test it locally, run

fastly copute serve

To deploy it to Fastly, run

fastly compute publish

Services Architecture

Option1: C@E to VCL

Not recommended because:

• All requests will be subject to redirection rule checks and have an additional delay for interaction with redirection.io.
• Redirect responses generated by C@E are not cached. C@E can cache responses coming from backends servers, but cannot cache responses it generates (As of Jan 2023. This restriction should be lifted once the Cache API becomes available)
• More requests/bandwidth to be billed

sequenceDiagram
    autonumber
    participant Client1
    participant Client2
    participant C@E
    participant redirection.io
    participant VCL
    participant Origin
    Client1->>C@E: Request GET /foo
    C@E->>redirection.io: POST
    redirection.io->>C@E: 200
    Note over C@E: Redirection rule found
    C@E->>Client1: 301
    Client1->>C@E: GET /bar
    C@E->>redirection.io: POST
    redirection.io->>C@E: 200
    Note over C@E: Redirection rule not found
    C@E->>VCL: GET /bar
    VCL->>Origin: GET /bar
    Origin->>VCL: 200
    VCL->>VCL: Cache!
    VCL->>C@E: 200
    C@E->>Client1: 200
    rect rgba(255, 235, 235, 0.6)
    opt Request from another client
        Client2->>C@E: GET /foo
        C@E->>redirection.io: POST
        redirection.io->>C@E: 200
        Note over C@E: Redirection rule found
        C@E->>Client2: 301
        Client2->>C@E: GET /bar
        C@E->>redirection.io: POST
        redirection.io->>C@E: 200
        Note over C@E: Redirection rule not found
        C@E->>VCL: GET /bar
        VCL->>VCL: HIT!
        VCL->>C@E: 200
        C@E->>Client2: 200
    end
    end

Option2: VCL to C@E (Recommended)

• Only cache misses are subject to redirection rule checks
• Both the responses from backend servers and the responses generated by C@E are cached
• Fewer requests/bandwidth to be billed
• In terms of caching, this is similar to when redirection.io is integrated into the origin server.

Other considerations

• To avoid purging issues, caching should be disabled on the C@E service. It shouldn't be difficult, but would require changes in the C@E code.

sequenceDiagram
    autonumber
    participant Client1
    participant Client2
    participant VCL
    participant C@E
    participant redirection.io
    participant Origin
    Client1->>VCL: Request GET /foo
    VCL->>C@E: Request GET /foo
    C@E->>redirection.io: POST
    redirection.io->>C@E: 200
    Note over C@E: Redirection rule found
    C@E->>VCL: 301
    VCL->>VCL: Cache!
    VCL->>Client1: 301
    Client1->>VCL: GET /bar
    VCL->>C@E: GET /bar
    C@E->>redirection.io: POST
    redirection.io->>C@E: 200
    Note over C@E: Redirection rule not found
    C@E->>Origin: GET /bar
    Origin->>C@E: 200
    C@E->>VCL: 200
    VCL->>VCL: Cache!
    VCL->>Client1: 200
    rect rgba(255, 235, 235, 0.6)
    opt Request from another client
        Client2->>VCL: GET /foo
        VCL->>VCL: HIT!
        VCL->>Client2: 301
        Client2->>VCL: GET /bar
        VCL->>VCL: HIT!
        VCL->>Client2: 200
    end
    end