GitLab Pages 리다이렉트
GitLab v19.5Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
요약
GitLab Pages에서는 Netlify 스타일 HTTP 리다이렉트를 사용하여 한 URL을 다른 URL로 전달하는 규칙을 구성할 수 있습니다. Netlify가 제공하는 특수 옵션이 모두 지원되는 것은 아닙니다. 매칭 동작 테스트 케이스는 GitLab이 규칙 매칭을 어떻게 구현하는지 자세히 이해하는 데 유용한 자료입니다.
GitLab Pages에서는 Netlify 스타일 HTTP 리다이렉트를 사용하여 한 URL을 다른 URL로 전달하는 규칙을 구성할 수 있습니다.
Netlify가 제공하는 특수 옵션이 모두 지원되는 것은 아닙니다.
| 기능 | 지원 여부 | 예시 |
|---|---|---|
리다이렉트 (301, 302) |
✅ | /wardrobe.html /narnia.html 302 |
리라이트 (200) |
✅ | /* / 200 |
| 스플랫 | ✅ | /news/* /blog/:splat |
| 플레이스홀더 | ✅ | /news/:year/:month/:date /blog-:year-:month-:date.html |
리라이트 (200 제외) |
❌ | /en/* /en/404.html 404 |
| 쿼리 매개변수 | ❌ | /store id=:id /blog/:id 301 |
| Force (섀도잉) | ❌ | /app/ /app/index.html 200! |
| 도메인 수준 리다이렉트 | ✅ | http://blog.example.com/* https://www.example.com/blog/:splat 301 |
| 국가 또는 언어별 리다이렉트 | ❌ | / /anz 302 Country=au,nz |
| 권한별 리다이렉트 | ❌ | /admin/* 200! Role=admin |
매칭 동작 테스트 케이스는 GitLab이 규칙 매칭을 어떻게 구현하는지 자세히 이해하는 데 유용한 자료입니다. 이 테스트 스위트에 포함되지 않은 예외 사례에 대한 커뮤니티 기여를 환영합니다.
리다이렉트 만들기#
리다이렉트를 만들려면 GitLab Pages 사이트의 public/ 디렉터리에
_redirects라는 구성 파일을 만듭니다.
-
모든 경로는 슬래시
/로 시작해야 합니다. -
상태 코드를 지정하지 않으면 기본 상태 코드
301이 적용됩니다. -
_redirects파일에는 인스턴스에 구성된 파일 크기 제한과 프로젝트당 최대 규칙 수가 있습니다. 구성된 최대 개수 안에서 처음 일치하는 규칙만 처리됩니다. 기본 파일 크기 제한은 64 KB이고, 기본 최대 규칙 수는 1,000개입니다. -
GitLab Pages 사이트가 기본 도메인 이름(예:
namespace.gitlab.io/project-slug)을 사용하는 경우 모든 규칙 앞에 경로를 붙여야 합니다:/project-slug/wardrobe.html /project-slug/narnia.html 302 -
GitLab Pages 사이트가 사용자 지정 도메인을 사용하는 경우 프로젝트 경로 접두사는 필요하지 않습니다. 예를 들어 사용자 지정 도메인이
example.com이면_redirects파일은 다음과 같습니다:/wardrobe.html /narnia.html 302
파일이 리다이렉트보다 우선#
파일은 리다이렉트보다 우선합니다. 디스크에 파일이 있으면 GitLab Pages는 리다이렉트 대신
해당 파일을 제공합니다. 예를 들어 hello.html과 world.html 파일이 있고
_redirects 파일에 다음 줄이 포함되어 있으면, hello.html 이 존재하므로 리다이렉트는
무시됩니다:
/project-slug/hello.html /project-slug/world.html 302
GitLab은 이 동작을 바꾸는 Netlify force 옵션을 지원하지 않습니다.
HTTP 상태 코드#
상태 코드를 지정하지 않으면 기본 상태 코드 301 이 적용되지만,
직접 지정할 수도 있습니다. 지원되는 HTTP 코드는 다음과 같습니다:
- 301: 영구 리다이렉트.
- 302: 임시 리다이렉트.
- 200: 성공한 HTTP 요청에 대한 표준 응답. Pages는
to규칙의 콘텐츠가 존재하면 주소 표시줄의 URL을 바꾸지 않고 해당 콘텐츠를 제공합니다.
리다이렉트#
리다이렉트를 만들려면 from 경로, to 경로, HTTP 상태 코드를
포함하는 규칙을 추가합니다:
# 301 permanent redirect
/old/file.html /new/file.html 301
# 302 temporary redirect
/old/another_file.html /new/another_file.html 302
리라이트#
요청이 from과 일치할 때 to 경로의 콘텐츠를 제공하려면 상태 코드 200을
지정합니다:
/old/file.html /new/file.html 200
이 상태 코드는 스플랫 규칙과 함께 사용하여 URL을 동적으로 재작성할 수 있습니다.
도메인 수준 리다이렉트#
히스토리
- GitLab 16.8에서
FF_ENABLE_DOMAIN_REDIRECT라는 기능 플래그와 함께 도입. 기본적으로 비활성화됨. - GitLab 16.9에서 GitLab.com에서 활성화.
- GitLab 16.10에서 GitLab Self-Managed 및 GitLab Dedicated에서 활성화.
- GitLab 17.4에서 일반 공급. 기능 플래그
FF_ENABLE_DOMAIN_REDIRECT제거됨.
도메인 수준 리다이렉트를 만들려면 다음 중 하나에 도메인 수준 경로(http:// 또는
https://로 시작)를 추가합니다:
to경로에만 추가합니다.from과to경로 모두에 추가합니다.
지원되는 HTTP 상태 코드는 301과 302 입니다:
# 301 permanent redirect
http://blog.example.com/file_1.html https://www.example.com/blog/file_1.html 301
/file_2.html https://www.example.com/blog/file_2.html 301
# 302 temporary redirect
http://blog.example.com/file_3.html https://www.example.com/blog/file_3.html 302
/file_4.html https://www.example.com/blog/file_4.html 302
도메인 수준 리다이렉트는 스플랫 규칙(스플랫 플레이스홀더 포함)과 함께 사용하여 URL 경로를 동적으로 재작성할 수 있습니다.
스플랫#
from 경로에 별표(*)가 있는 규칙을 스플랫이라고 하며, 요청 경로의 시작, 중간,
끝에 있는 모든 내용과 일치합니다. 다음 예시는 /old/ 뒤의 모든 내용과 일치하고
이를 /new/file.html로 재작성합니다:
/old/* /new/file.html 200
스플랫 플레이스홀더#
규칙의 from 경로에서 *에 일치한 콘텐츠는 :splat 플레이스홀더를 사용하여
to 경로에 삽입할 수 있습니다:
/old/* /new/:splat 200
이 예시에서 /old/file.html 요청은 /new/file.html의 콘텐츠를 상태 코드 200으로
제공합니다.
규칙의 from 경로에 스플랫이 여러 개 있으면 첫 번째 스플랫에 일치한 값이
to 경로의 모든 :splat을 대체합니다.
스플랫 매칭 동작#
스플랫은 "탐욕적"이어서 가능한 한 많은 문자와 일치합니다:
/old/*/file /new/:splat/file 301
이 예시에서 규칙은 /old/a/b/c/file을 /new/a/b/c/file로 리다이렉트합니다.
스플랫은 빈 문자열과도 일치하므로, 앞의 규칙은
/old/file을 /new/file로 리다이렉트합니다.
스플랫으로 파일 확장자 일치#
from 경로에서 스플랫은 파일 확장자 바로 앞에 올 수 있습니다. 예를 들어 다음 규칙은 모든 .html 요청과 일치하고, 확장자 없이 끝에 슬래시를 붙인 같은 경로로 리다이렉트합니다:
/*.html /:splat/ 301
이 예시에서 /page.html 요청은 /page/로, /docs/page.html 요청은 /docs/page/로 리다이렉트됩니다.
모든 요청을 루트 index.html로 재작성#
단일 페이지 애플리케이션(SPA)은 클라이언트 측 라우트를 사용하여 자체 라우팅을
수행하는 경우가 많습니다. 이러한 애플리케이션에서는 라우팅 로직을 JavaScript
애플리케이션이 처리할 수 있도록 모든 요청을 루트 index.html로
재작성합니다.
요청을 index.html로 재작성하려면:
-
다음
_redirects규칙을 추가합니다:/* /index.html 200 -
단일 페이지 애플리케이션이 병렬 배포에서 동작하도록 하려면 리다이렉트 규칙을 수정하여 경로 접두사를 포함합니다:
/project/base/<prefix>/* /project/base/<prefix>/index.html 200<prefix>를 사용 중인 경로 접두사 값으로 바꿉니다.
플레이스홀더#
규칙에 플레이스홀더를 사용하면 요청 URL의 일부와 일치시키고, 새 URL로 재작성하거나 리다이렉트할 때 그 일치 값을 사용할 수 있습니다.
플레이스홀더는 from과 to 경로 모두에서 : 문자 뒤에 문자열
([a-zA-Z]+)이 오는 형식입니다:
/news/:year/:month/:date/:slug /blog/:year-:month-:date-:slug 200
이 규칙은 /news/2021/08/12/file.html 요청에 대해 Pages가
/blog/2021-08-12-file.html의 콘텐츠를 200으로 제공하도록 지시합니다.
플레이스홀더 매칭 동작#
스플랫과 비교하면 플레이스홀더는 일치시키는 콘텐츠의 범위가
더 제한적입니다. 플레이스홀더는 슬래시(/) 사이의 텍스트와 일치하므로,
단일 경로 세그먼트를 일치시킬 때 사용합니다.
또한 플레이스홀더는 빈 문자열과 일치하지 않습니다. 다음과 같은 규칙은
/old/file 같은 요청 URL과 일치하지 않습니다:
/old/:path /new/:path
리다이렉트 규칙 디버그#
리다이렉트가 예상대로 동작하지 않거나 리다이렉트 구문을 확인하려면
[your pages url]/_redirects에 접속합니다. _redirects 파일은 직접 제공되지 않지만, 브라우저에
리다이렉트 규칙이 번호가 매겨진 목록으로 표시되고 각 규칙의 유효 여부도 함께 표시됩니다:
11 rules
rule 1: valid
rule 2: valid
rule 3: error: splats are not supported
rule 4: valid
rule 5: error: placeholders are not supported
rule 6: valid
rule 7: error: no domain-level redirects to outside sites
rule 8: error: url path must start with forward slash /
rule 9: error: no domain-level redirects to outside sites
rule 10: valid
rule 11: valid
Netlify 구현과의 차이점#
지원되는 대부분의 _redirects 규칙은 GitLab과 Netlify에서 동일하게 동작합니다.
다만 몇 가지 사소한 차이가 있습니다:
-
모든 규칙 URL은 슬래시로 시작해야 합니다:
Netlify는 URL이 슬래시로 시작하도록 요구하지 않습니다:
# Valid in Netlify, invalid in GitLab */path /new/path 200GitLab은 모든 URL이 슬래시로 시작하는지 검증합니다. 앞 예시에 해당하는 유효한 표기는 다음과 같습니다:
# Valid in both Netlify and GitLab /old/path /new/path 200 -
모든 플레이스홀더 값이 채워집니다:
Netlify는
to경로에 나타나는 플레이스홀더 값만 채웁니다:/old /new/:placeholder/old요청이 들어오면:- Netlify는
/new/:placeholder로 리다이렉트합니다(문자 그대로의:placeholder). - GitLab은
/new/로 리다이렉트합니다.
- Netlify는