[BUG] `contenttypes` keys with Lua pattern special characters (e.g. +) fail to match response Content-Type headers

[Chris-Robertson]

Description

Content types containing characters that are special in Lua patterns (such as +, -, .) fail to match response Content-Type headers when used as keys in the contenttypes config option.

Steps to Reproduce

Add the following to your kulala config:

contenttypes = {
    ["application/hal+json"] = "application/json",
}

Make a request to an endpoint that responds with Content-Type: application/hal+json. The response body will be treated as plain text instead of JSON.

The response buffer :set filetype? will return text.kulala_ui, when it should be json.kulala_ui.

Impact

The response body is not formatted.

This may also affect the built-in default mapping ["application/graphql-response+json"], which contains both + and -, both special characters in Lua patterns, meaning that mapping may also not work as intended. Though I have not tested this.

Root Cause

In

kulala.nvim/lua/kulala/internal_processing/init.lua

Lines 130 to 132 in 6656c9d

	local config_key = vim.iter(CONFIG.get().contenttypes):find(function(k, _)
	return content_type:match(k)
	end)

, the contenttypes key is used directly as a Lua pattern.

Because k is passed to string.match as a pattern rather than a plain string, any key containing Lua pattern special characters (+, -, ., *, ?, [, ], ^, $, %, (, )) will not behave as expected.

For example, the key "application/hal+json" is interpreted as the pattern application/hal+json, where l+ means "one or more l characters".

Workaround

Escape special characters manually in your config keys using %

contenttypes = {
    ["application/hal%+json"] = "application/json",
}

Suggested Fix

Escape keys with vim.pesc() before using them as patterns.

local config_key = vim.iter(CONFIG.get().contenttypes):find(function(k, _)
  return content_type:match(vim.pesc(k))
end)

I would be happy to raise a PR for this, but I wanted to check I'm not barking up the wrong tree first.

Request

Any request that responds with Content-Type: application/hal+json.

Here is an example from https://httpbin.org/

GET https://httpbin.org/response-headers?Content-Type=application/hal+json

Error

No error happens, but the response body is not formatted.

Health

System:
ℹ {OS} Darwin 25.3.0
ℹ {Neovim} version 0.12.0
ℹ {kulala.nvim} version 5.3.4

Tools:
✔ {cURL} found: /usr/bin/curl (version: 8.7.1)
✘ {gRPCurl} not found
✘ {websocat} not found
✔ {openssl} found: /opt/homebrew/bin/openssl (version: 3.6.1)
✔ {NPM} found: /Users/chris.robertson/.asdf/shims/npm (version: unknown)

Formatters:
✔ {application/json} formatter: jq .
✔ {application/javascript} formatter: prettier --stdin-filepath file.js
⚠ {application/lua} formatter not found
✔ {application/graphql} formatter: prettier --stdin-filepath file.graphql
✔ {text/html} formatter: prettier --stdin-filepath file.html
✔ {application/graphql-response+json} formatter: jq .
✔ {application/xml} formatter: xmllint --format -
✔ {application/hal+json} formatter: jq .

User Config

{
  additional_curl_options = { "--insecure" },
  contenttypes = {
    ["application/hal+json"] = "application/json"
  },
  debug = 4,
  default_env = "tunnel",
  global_keymaps = true,
  urlencode = "always"
}

[gorillamoe]

We could do this as an intermediate fix. If we switch to kulala-core at some point, stuff isn't necessary anymore, because it works completely different and it also takes care of telling you what the response is:

The example http file you provided yields this result in the current kulala-core implementation:

{
  "type": "responses",
  "data": [
    {
      "success": true,
      "status": 200,
      "headers": {
        "date": "Wed, 25 Feb 2026 15:12:14 GMT",
        "content-type": "application/hal json",
        "content-length": "108",
        "connection": "keep-alive",
        "access-control-allow-origin": "*",
        "access-control-allow-credentials": "true",
        "server": "gunicorn/19.9.0"
      },
      "url": "https://httpbin.org/response-headers?Content-Type=application/hal+json",
      "timings": {
        "dns": 0,
        "tcp": 2.720835000000001,
        "tls": 0,
        "request": 0.09098099999999931,
        "redirect": 0,
        "firstByte": 479.68874400000004,
        "startTransfer": 489.10769100000005,
        "total": 490.18394
      },
      "body": {
        "type": "json",
        "content": {
          "Content-Length": "108",
          "Content-Type": [
            "application/json",
            "application/hal json"
          ]
        }
      }
    }
  ]
}

It produces a body of type json with the correct values, because + is treated as a space.

But even with this weird returned content type, it's a JSON.

It works with this one too:

### REQUEST_JSON_CONTENT_TYPE

GET https://httpbin.org/response-headers?Content-Type=application/hal%2Bjson
Content-Type: application/json

yields:

{
  "type": "responses",
  "data": [
    {
      "success": true,
      "status": 200,
      "headers": {
        "date": "Wed, 25 Feb 2026 15:16:43 GMT",
        "content-type": "application/hal+json",
        "content-length": "108",
        "connection": "keep-alive",
        "access-control-allow-origin": "*",
        "access-control-allow-credentials": "true",
        "server": "gunicorn/19.9.0"
      },
      "url": "https://httpbin.org/response-headers?Content-Type=application/hal%2Bjson",
      "timings": {
        "dns": 0,
        "tcp": 3.6575600000000037,
        "tls": 0,
        "request": 0.19829000000000008,
        "redirect": 0,
        "firstByte": 460.697457,
        "startTransfer": 473.112062,
        "total": 477.174202
      },
      "body": {
        "type": "json",
        "content": {
          "Content-Length": "108",
          "Content-Type": [
            "application/json",
            "application/hal+json"
          ]
        }
      }
    }
  ]
}

And this is the result of "zero-config" atm, so nothing special here.

It's bascially best-guessing what the content type might be. Something like "if there is the string json in the returned content type, let's try to parse it as JSON, if it succeeds, yay, we have a JSON body..".

I just checked the behaviour of Postman and it seems that they are doing something similar, because both examples return a parsed JSON in their UI. If I omit the n of json then Postman doesn't show a proper JSON response, but defaults to a text view.