URL.parse() 메서드를 활용하여 URL 객체를 생성하고 처리하는 방법

• URL.parse(url) 메서드는 주어진 URL에 따라 새 URL 객체를 생성
• 유효하지 않은 URL 값이 주어질 경우 null을 반환
• 두 번째 파라미터 base는 상대 URL을 해석하기 위한 기준 URL로 사용되며, 이를 통해 URL의 경로가 올바르게 조정됨
• URL 객체나 다른 문자열을 파라미터로 사용할 수 있으며, 내부에서 문자열로 변환됨

describe('null 입력에 대한 URL API 동작 테스트', () => {
  test('new URL(null)은 TypeError를 발생시킨다', () => {
    expect(() => new URL(null)).toThrow(TypeError)
  })

  test('URL.canParse(null)은 false를 반환한다', () => {
    expect(URL.canParse(null)).toBe(false)
  })

  test('URL.parse(null)은 null을 반환한다', () => {
    expect(() => URL.parse(null)).toBe(null)
  })
})

URL %2520 버그 = iOS 17.0/17.1 WebKit pasteboard가 복사 시 URL을 재인코딩 (WebKit Bug 261936).

현상

• 공백이 %2520으로 깨짐, 한글은 %EC%88%98 정상 → 부분 재인코딩
• 복사-붙여넣기 경로만 영향, 클릭(JS redirect)은 정상
• iOS 집중 + referrer 누락 패턴과 일치

원인

%2520 = %25(= %) + 원래 있던 20. 공백(%20)이 한 번 더 인코딩된 것.

공백 → %20 → (% 만 재인코딩) → %2520

URL 인코딩은 멱등(idempotent)이 아니다 — encodeURIComponent를 두 번 하면 값이 달라진다.

진범은 WebKit Bug 261936:

• iOS 16↓: NSURL URLWithString:이 invalid char에 nil
• iOS 17.0/17.1: invalid char를 자동 percent-encode (regression)
• iOS 17.2: 수정

pasteboard가 NSURL을 만들 때 %20은 invalid로 잘못 판단해 재인코딩, 한글 percent-encoding(%EA%B0%80)은 valid UTF-8로 통과 → 비대칭의 원인.

해결

원인이 외부(OS 버그)면 추적보다 방어가 ROI 높음.

• 화이트리스트 라우트 패턴에서만 디코딩
• 디코딩 후 위험 패턴(.., //, \) 차단
• segment별 encodeURIComponent 후 301 redirect

교훈

• URL은 디코딩된 원본으로 보관, 인코딩은 출력 직전 한 번 (single source of truth)
• “방어적으로 한 번 더”가 함정 — 멱등이 아닌 연산엔 통하지 않는다

참고

• WebKit Bug 261936
• Changes to URL string parsing in iOS 17 — Augmented Code
• OWASP — Double Encoding
• WHATWG URL Standard