JavaScript Ready | Программирование

URL.canParse + URL API — проверка URL без try/catch и regex!

Частая задача в JS: проверить URL перед fetch, редиректом, сохранением в БД, проксированием или обработкой пользовательского ввода.

Обычно многие делают так:

function isValid(url) {
  try {
    new URL(url);

    return true;
  } catch {
    return false;
  }
}

Способ рабочий, но со временем такие проверки начинают размножаться по проекту в десятках мест. Минусы:— try/catch ради обычной проверки читается тяжеловато— многие потом начинают дописывать сверху regex— появляются разные реализации одной и той же логики.

Но в платформе есть нативный способ — URL.canParse().

URL.canParse("https://example.com");
// true

URL.canParse("not-a-url");
// false

Без исключений и без самописных проверок. Просто получаешь boolean.

Но тут есть важный момент, про который многие забывают — относительные URL. Например:

URL.canParse("/api/users");
// false

Это не ошибка метода. Просто относительный путь нельзя распарсить без base URL. Поэтому правильно так:

URL.canParse(
  "/api/users",
  "https://example.com"
);
// true

И потом этот же base используешь при создании URL:

const url = new URL(
  "/api/users",
  "https://example.com"
);

Это особенно полезно в SSR, middleware, proxy и серверных обработчиках, где часто работают именно с относительными путями.

Ещё хороший кейс — фильтрация пользовательского ввода.

const input = [
  "https://a.com",
  "ftp://b.com",
  "invalid"
];

const valid = input.filter(u =>
  URL.canParse(u)
);

Но тут есть нюанс, canParse() проверяет только то, что строка корректно парсится как URL с точки зрения WHATWG URL parser. Это не проверка безопасности и не проверка того, что URL подходит именно для вашего кейса.

Например ftp: или даже javascript: тоже могут успешно парситься. Поэтому для API, fetch и редиректов обычно дополнительно проверяют protocol:

function parseHttpUrl(u) {
  if (!URL.canParse(u)) {
    return null;
  }

  const url = new URL(u);

  return (
    url.protocol === "http:" ||
    url.protocol === "https:"
  )
    ? url
    : null;
}

А для редиректов и proxy этого тоже часто недостаточно — обычно дополнительно проверяют hostname/origin через allowlist.

Ещё один полезный момент — нормализация URL. Очень часто одинаковые ссылки приходят в разном виде:

https://example.com
https://example.com/

Через URL API это можно привести к одному формату:

function normalize(u) {
  if (!URL.canParse(u)) {
    return null;
  }

  return new URL(u).href;
}

normalize("https://example.com");
normalize("https://example.com/");

🔥 В итоге: если нужно проверить, разобрать или нормализовать URL — лучше сразу использовать стандартный URL API. Кода меньше, поведение предсказуемее и меньше шансов словить странные баги на парсинге.

📣

JS Ready | #практика

Please open Telegram to view this post