https://github.com/greenpau/caddy-trace

Request Debugging Middleware Plugin for Caddy v2
https://github.com/greenpau/caddy-trace

caddy caddy-plugin debug debugging debugging-tool

Last synced: 16 days ago
JSON representation

Request Debugging Middleware Plugin for Caddy v2

• Host: GitHub
• URL: https://github.com/greenpau/caddy-trace
• Owner: greenpau
• License: apache-2.0
• Created: 2020-09-06T14:15:50.000Z (almost 4 years ago)
• Default Branch: main
• Last Pushed: 2023-12-02T22:16:53.000Z (7 months ago)
• Last Synced: 2024-05-16T20:56:30.645Z (about 2 months ago)
• Topics: caddy, caddy-plugin, debug, debugging, debugging-tool
• Language: Go
• Homepage:
• Size: 369 KB
• Stars: 59
• Watchers: 4
• Forks: 6
• Open Issues: 1
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Lists

• awesome-starred - greenpau/caddy-trace - Request Debugging Middleware Plugin for Caddy v2 (others)
• awesome-stars - greenpau/caddy-trace - Request Debugging Middleware Plugin for Caddy v2 (Go)

README

        
# caddy-trace









Request Debugging Middleware Plugin for [Caddy v2](https://github.com/caddyserver/caddy).

## Table of Contents

* [Overview](#overview)

* [Getting Started](#getting-started)

## Overview

The plugin is a middleware which displays the content of the request it

handles. It helps troubleshooting web requests by exposing headers

(e.g. cookies), URL parameters, etc.

For background, the idea for the creation of plugin came during a

development of another plugin which rewrites headers of web requests.

There was a need to compare "before and after" content of the request.

The `trace` directive gets inserted prior to the plugin which

modifies a request and immediately after it. The log with the content

of the request show up twice and it is easy to compare the two.

## Getting Started

Add `trace` handler to enable this plugin.

The `disabled=yes` argument disables the operation of the plugin.

The `tag` argument injects the value in the log output. This way, one can have

multiple handlers and there is a way to deferentiate between them.

The `response_debug` argument instructs the plugin to buffer

responses and log response related metadata, i.e. status codes, length, etc.

The `uri_filter` directive instructs the plugin to intercepts only

the requests with the URI matching the regular expression in the filter.

When a request arrives for `/version`, the plugin will be triggered two (2)

times. The first handler is disables. The two (2) other handlers will trigger

with different tags. The `respond` handler is terminal and it means the handler

with `marvel` tag will not trigger.

When a request arrives for `/whoami`, the plugin will be triggered three (2)

times because `respond /version` will not terminate the handling of the plugin.

Notably, the plugin will output response metadata due to the presence of

`response_debug` argument.

```

{

  http_port     9080

  https_port    9443

}

localhost:9080 {

  route {

    trace disabled=yes

    trace disabled=no tag="foo"

    trace disabled=no tag="bar"

    respond /version "1.0.0" 200

    trace tag="marvel" response_debug=yes

    trace tag="custom" response_debug=yes uri_filter="^/whoami$"

    respond /whoami 200 {

      body "greenpau"

    }

  }

}

```