Игнорирование параметров GET в Varnish VCL

Хорошо: у меня настроен сайт с некоторыми API-интерфейсами, которые мы предоставляем разработчикам в формате

/api/item.xml?type_ids=34,35,37&region_ids=1000002,1000003&key=SOMERANDOMALPHANUM

В этом URI всегда устанавливается type_ids, region_ids и key необязательны.

Важно отметить, что ключевая переменная не влияет на содержимое ответа. Он используется для внутреннего отслеживания запросов, чтобы мы могли идентифицировать людей, которые делают медленные или нежелательные запросы.

В Varnish у нас есть такой VCL:

if (req.http.host ~ "the-site-in-question.com") {
  if (req.url ~ "^/api/.+\.xml") {
    unset req.http.cookie;
  }
}

Мы просто удаляем файлы cookie и позволяем бэкэнду делать все остальное, насколько это возможно (это обходной путь, поскольку Rails / authlogic отправляет файлы cookie сеанса с ответами API).

Однако в настоящее время отдельные разработчики в основном используют разные кеши, поскольку &key=SOMEALPHANUM рассматривается как часть хэша Varnish для хранения. Это явно не лучшее решение, и я пытаюсь понять, как сказать Varnish игнорировать эту часть URI.

Если вам нужно оставить key=SOMEALPHANUM в целости и сохранности на бэкэнд, если он не доставлен из кеша, тогда было бы лучше regsub в пределах vcl_hash функция вместо этого, так как это на самом деле не изменит URL-адрес, а просто изменит хэш ключа.

sub vcl_hash {
  if(req.http.host ~ "the-site-in-question.com" & req.url ~ "^/api/") {
    set req.http.X-Sanitized-URL = req.url;
    set req.http.X-Sanitized-URL = regsub(req.http.X-Sanitized-URL, "&key=[A-Za-z0-9]+", "");
    set req.hash += req.http.X-Sanitized-URL;
  } else {
    set req.hash += req.url;
  }
  set req.hash += req.http.host;
  hash;
}

в vcl_recv

установить req.url = regsub (req.url, "& key =. * $", "");

Аналогично ответу cd34, но с учетом возможности разных порядков параметров запроса и с учетом того, что проблема определяет значение как буквенно-цифровое:

set req.url = regsub(req.url, "&key=[A-Za-z0-9]*", "");

(Пока не могу комментировать, иначе это был бы комментарий к ответу cd34)