Apache에서 리디렉션, URL 변경 또는 HTTP를 HTTPS로 리디렉션 - mod_rewrite 규칙에 대해 알고 싶었지만 물어보기 두려웠던 모든 것

Apache에서 리디렉션, URL 변경 또는 HTTP를 HTTPS로 리디렉션 - mod_rewrite 규칙에 대해 알고 싶었지만 물어보기 두려웠던 모든 것

이것은정식 질문Apache의 mod_rewrite에 대해

요청 URL을 변경하거나 사용자를 원래 요청한 것과 다른 URL로 리디렉션하는 작업은 mod_rewrite를 사용하여 수행됩니다. 여기에는 다음이 포함됩니다.

  • HTTP를 HTTPS로 변경(또는 그 반대)
  • 더 이상 존재하지 않는 페이지에 대한 요청을 새로운 대체 페이지로 변경합니다.
  • URL 형식 수정(예: ?id=3433 ~ /id/3433 )
  • 달과 태양 아래 가능한 모든 것을 기반으로 브라우저 기반, 리퍼러 기반으로 다른 페이지를 표시합니다.
  • URL로 어지럽히고 싶은 모든 것

Mod_Rewrite 규칙에 대해 알고 싶었지만 물어보기 두려웠던 모든 것!

mod_rewrite 규칙 작성 전문가가 되려면 어떻게 해야 합니까?

  • mod_rewrite 규칙의 기본 형식과 구조는 무엇입니까?
  • 정규식의 어떤 형식/특징을 확실히 이해해야 합니까?
  • 재작성 규칙을 작성할 때 가장 흔히 발생하는 실수/함정은 무엇입니까?
  • mod_rewrite 규칙을 테스트하고 확인하는 좋은 방법은 무엇입니까?
  • 내가 알아야 할 mod_rewrite 규칙이 SEO 또는 성능에 미치는 영향이 있습니까?
  • mod_rewrite가 작업에 적합한 도구처럼 보이지만 그렇지 않은 일반적인 상황이 있습니까?
  • 몇 가지 일반적인 예는 무엇입니까?

규칙을 테스트할 수 있는 장소

그만큼htaccess 테스터웹사이트는 규칙을 가지고 놀고 테스트할 수 있는 좋은 장소입니다. 디버그 출력도 표시하므로 일치하는 항목과 일치하지 않는 항목을 확인할 수 있습니다.

답변1

mod_rewrite 구문 순서

mod_rewrite에는 처리에 영향을 미치는 특정 순서 규칙이 있습니다. 어떤 작업을 수행하기 전에 RewriteEngine Onmod_rewrite 처리가 활성화되도록 지시문을 제공해야 합니다. 이는 다른 재작성 지시문 앞에 와야 합니다.

RewriteCond이전에는 RewriteRule하나의 규칙에 조건이 적용됩니다. 다음 RewriteRules는 조건이 적용되지 않는 것처럼 처리됩니다.

RewriteEngine On
RewriteCond %{HTTP_REFERER}          ^https?://serverfault\.com(/|$)
RewriteRule $/blog/(.*)\.html        $/blog/$1.sf.html

이 간단한 경우, HTTP 리퍼러가 serverfault.com에서 온 경우 블로그 요청을 특별한 serverfault 페이지로 리디렉션합니다(우리는 그만큼 특별합니다). 그러나 위 블록에 추가 RewriteRule 줄이 있는 경우:

RewriteEngine On
RewriteCond %{HTTP_REFERER}          ^https?://serverfault\.com(/|$)
RewriteRule $/blog/(.*)\.html        $/blog/$1.sf.html
RewriteRule $/blog/(.*)\.jpg         $/blog/$1.sf.jpg

모든 .jpg 파일은 여기에서 왔다는 것을 나타내는 리퍼러가 있는 파일뿐만 아니라 특수한 서버 오류 페이지로 이동합니다. 이는 분명히 이러한 규칙이 작성되는 방식의 의도가 아닙니다. 여러 RewriteCond 규칙을 사용하여 수행할 수 있습니다.

RewriteEngine On
RewriteCond %{HTTP_REFERER}          ^https?://serverfault\.com(/|$)
RewriteRule ^/blog/(.*)\.html        /blog/$1.sf.html
RewriteCond %{HTTP_REFERER}          ^https?://serverfault\.com(/|$)
RewriteRule ^/blog/(.*)\.jpg         /blog/$1.sf.jpg

그러나 아마도 좀 더 까다로운 대체 구문을 사용하여 수행해야 할 것입니다.

RewriteEngine On
RewriteCond %{HTTP_REFERER}                ^https?://serverfault\.com(/|$)
RewriteRule ^/blog/(.*)\.(html|jpg)        /blog/$1.sf.$2

더 복잡한 RewriteRule에는 처리를 위한 조건이 포함되어 있습니다. 마지막 괄호는 (html|jpg)RewriteRule에게 또는 에 대해 일치하고 html일치 jpg하는 문자열을 다시 작성된 문자열에서 $2로 나타내도록 지시합니다. 이는 두 개의 RewriteCond/RewriteRule 쌍이 있는 이전 블록과 논리적으로 동일하며 4개가 아닌 2개의 라인에서만 수행됩니다.

여러 RewriteCond 행은 암시적으로 AND로 연결되며 명시적으로 OR로 연결될 수 있습니다. ServerFault 및 슈퍼 유저 모두의 리퍼러를 처리하려면(명시적 OR):

RewriteEngine On
RewriteCond %{HTTP_REFERER}                ^https?://serverfault\.com(/|$)    [OR]
RewriteCond %{HTTP_REFERER}                ^https?://superuser\.com(/|$)
RewriteRule ^/blog/(.*)\.(html|jpg)        /blog/$1.sf.$2

Chrome 브라우저를 사용하여 ServerFault 참조 페이지를 제공하려면(암시적 AND):

RewriteEngine On
RewriteCond %{HTTP_REFERER}                ^https?://serverfault\.com(/|$)
RewriteCond %{HTTP_USER_AGENT}             ^Mozilla.*Chrome.*$
RewriteRule ^/blog/(.*)\.(html|jpg)        /blog/$1.sf.$2

RewriteBaseRewriteRule또한 다음 지시문이 처리를 처리하는 방법을 지정하므로 주문에 따라 다릅니다 . .htaccess 파일에 매우 유용합니다. 사용되는 경우 .htaccess 파일의 "RewriteEngine on" 아래 첫 번째 지시문이어야 합니다. 다음 예를 들어보세요.

RewriteEngine On
RewriteBase /blog
RewriteCond %{HTTP_REFERER}           ^https?://serverfault\.com(/|$)
RewriteRule ^(.*)\.(html|jpg)         $1.sf.$2

이는 mod_rewrite에 현재 처리 중인 특정 URL이 다음을 통해 도착했음을 알려줍니다.http://example.com/blog/실제 디렉터리 경로(/home/$Username/public_html/blog) 대신 적절하게 처리합니다. 이 때문에 에서는 RewriteRuleURL의 "/blog" 뒤에 문자열 시작이 있는 것으로 간주합니다. 여기에는 두 가지 다른 방식으로 작성된 동일한 내용이 있습니다. 하나는 RewriteBase가 있고 다른 하나는 다음이 없습니다.

RewriteEngine On

##Example 1: No RewriteBase##
RewriteCond %{HTTP_REFERER}                                   ^https?://serverfault\.com(/|$)
RewriteRule /home/assdr/public_html/blog/(.*)\.(html|jpg)     $1.sf.$2

##Example 2: With RewriteBase##
RewriteBase /blog
RewriteCond %{HTTP_REFERER}           ^https?://serverfault\.com(/|$)
RewriteRule ^(.*)\.(html|jpg)         $1.sf.$2

보시다시피 RewriteBase웹을 활용하기 위한 재작성 규칙을 허용합니다.대지웹이 아닌 콘텐츠로 가는 길섬기는 사람를 사용하면 해당 파일을 편집하는 사람이 더 쉽게 이해할 수 있습니다. 또한 지시문을 더 짧게 만들 수 있어 미적인 매력이 있습니다.


RewriteRule 일치 구문

RewriteRule 자체에는 문자열 일치를 위한 복잡한 구문이 있습니다. 플래그([PT]와 같은 것)에 대해서는 다른 섹션에서 다루겠습니다. 시스템 관리자는 책을 읽는 것보다 예를 통해 배우는 경우가 더 많기 때문입니다.맨페이지예를 들어 그들이 무엇을 하는지 설명하겠습니다.

RewriteRule ^/blog/(.*)$    /newblog/$1

구문 .*은 단일 문자( .)와 0회 이상( *) 일치합니다. 이를 괄호로 묶으면 $1 변수와 일치하는 문자열을 제공하라는 의미입니다.

RewriteRule ^/blog/.*/(.*)$  /newblog/$1

이 경우 첫 번째 .*는 괄호로 묶이지 않았으므로 다시 작성된 문자열에 제공되지 않습니다. 이 규칙은 새 블로그 사이트에서 디렉터리 수준을 제거합니다. (/blog/2009/sample.html은 /newblog/sample.html이 됩니다.)

RewriteRule ^/blog/(2008|2009)/(.*)$   /newblog/$2

이 경우 첫 번째 괄호 표현식은 일치하는 그룹을 설정합니다. 이는 $1이 되며 필요하지 않으므로 다시 작성된 문자열에 사용되지 않습니다.

RewriteRule ^/blog/(2008|2009)/(.*)$   /newblog/$1/$2

이 경우 다시 작성된 문자열에 $1을 사용합니다.

RewriteRule ^/blog/(20[0-9][0-9])/(.*)$   /newblog/$1/$2

이 규칙은 문자를 지정하는 특수 대괄호 구문을 사용합니다.범위. [0-9]는 0부터 9까지의 숫자와 일치합니다. 이 특정 규칙은 2000년부터 2099년까지의 연도를 처리합니다.

RewriteRule ^/blog/(20[0-9]{2})/(.*)$  /newblog/$1/$2

이는 이전 규칙과 동일한 작업을 수행하지만 {2} 부분은 이전 문자(이 경우 대괄호 표현식)와 두 번 일치하도록 지시합니다.

RewriteRule ^/blog/([0-9]{4})/([a-z]*)\.html   /newblog/$1/$2.shtml

이 경우 두 번째 일치 표현식의 모든 소문자와 일치하며 가능한 한 많은 문자에 대해 일치합니다. 구문은 \.기간을 이전 예의 특수 문자가 아닌 실제 기간으로 처리하도록 지시합니다. 하지만 파일 이름에 대시가 포함되어 있으면 문제가 발생합니다.

RewriteRule ^/blog/([0-9]{4})/([-a-z]*)\.html  /newblog/$1/$2.shtml

대시가 포함된 파일 이름을 트랩합니다. 그러나 -대괄호 표현식의 특수 문자와 마찬가지로첫 번째표현의 문자.

RewriteRule ^/blog/([0-9]{4})/([-0-9a-zA-Z]*)\.html   /newblog/$1/$2.shtml

-이 버전은 파일 이름에 문자, 숫자 또는 문자가 포함된 모든 파일 이름을 트랩합니다 . 이는 대괄호 표현식에 여러 문자 세트를 지정하는 방법입니다.


RewriteRule 플래그

재작성 규칙의 플래그에는 다양한 특별한 의미와 사용 사례가 있습니다..

RewriteRule ^/blog/([0-9]{4})/([-a-z]*).\html  /newblog/$1/$2.shtml  [L]

플래그는 [L]위 표현식의 끝에 있습니다. 여러 플래그를 쉼표로 구분하여 사용할 수 있습니다. 링크된 문서는 각각에 대해 설명하지만, 어쨌든 여기에 있습니다:

= 마지막. 이것이 일치하면 RewriteRules 처리를 중지합니다. 주문이 중요합니다!
= 체인. 다음 RewriteRule을 계속 처리합니다. 이 규칙이 일치하지 않으면 다음 규칙이 실행되지 않습니다. 이에 대해서는 나중에 자세히 설명합니다.
이자형= 환경변수를 설정합니다. Apache에는 웹 서버 동작에 영향을 미칠 수 있는 다양한 환경 변수가 있습니다.
에프= 금지되어 있습니다. 이 규칙이 일치하면 403-Forbidden 오류를 반환합니다.
G= 사라졌다. 이 규칙이 일치하면 410-Gone 오류를 반환합니다.
시간= 핸들러. 요청이 지정된 MIME 유형인 것처럼 처리되도록 합니다.
N= 다음. 규칙을 다시 시작하고 다시 일치시키도록 합니다. 조심하세요! 루프가 발생할 수 있습니다.
체크 안함= 사건 없음. jpgjpg와 JPG를 모두 일치시킬 수 있습니다 .
북동쪽= 탈출은 불가능하다. 특수 문자(. ? # & 등)를 해당하는 16진수 코드로 다시 쓰는 것을 방지합니다.
NS= 하위 요청이 없습니다. 서버 측 포함을 사용하는 경우 포함된 파일과의 일치가 방지됩니다.
= 프록시. mod_proxy가 규칙을 강제로 처리하도록 합니다. 웹 서버가 콘텐츠를 가져와서 다시 제공하므로 다른 서버의 콘텐츠를 투명하게 제공합니다. 이것은 위험한 플래그입니다. 제대로 작성되지 않은 플래그는 웹 서버를 개방형 프록시로 전환하므로 이는 좋지 않습니다.
PT= 통과. RewriteRule 일치에서 Alias ​​문을 고려하세요.
QSA= QS첨부. 원래 문자열에 쿼리(http://example.com/thing?asp=foo) 원래 쿼리 문자열을 다시 작성된 문자열에 추가합니다. 일반적으로 폐기됩니다. 동적 콘텐츠에 중요합니다.
아르 자형= 리디렉션. 지정된 URL에 HTTP 리디렉션을 제공합니다. 정확한 리디렉션 코드 [R=303]를 제공할 수도 있습니다. 와 매우 유사하며 RedirectMatch더 빠르며 가능하면 사용해야 합니다.
에스= 건너뛰기. 이 규칙을 건너 뛰십시오.
= 유형. 반환된 콘텐츠의 MIME 유형을 지정합니다. 지시문 과 매우 유사합니다 AddType.

RewriteCond내가 그것이 단 하나의 규칙에만 적용된다고 어떻게 말했는지 아시나요 ? 글쎄, 체인을 연결하면 이 문제를 해결할 수 있습니다.

RewriteEngine On
RewriteCond %{HTTP_REFERER}          ^https?://serverfault\.com(/|$)
RewriteRule ^/blog/(.*)\.html        /blog/$1.sf.html     [C]
RewriteRule ^/blog/(.*)\.jpg         /blog/$1.sf.jpg

첫 번째 RewriteRule에는 Chain 플래그가 있으므로 두 번째 rewrite-rule은 첫 번째 규칙이 실행될 때, 즉 이전 RewriteCond 규칙이 일치할 때 실행됩니다. Apache 정규 표현식으로 인해 머리가 아프면 편리합니다. 그러나 첫 번째 섹션에서 제가 지적한 올인원 라인 방식은 최적화 관점에서 볼 때 더 빠릅니다.

RewriteRule ^/blog/([0-9]{4})/([-0-9a-zA-Z]*)\.html   /newblog/$1/$2.shtml

이는 플래그를 통해 더 간단하게 만들 수 있습니다.

RewriteRule ^/blog/([0-9]{4})/([-0-9a-z]*)\.html   /newblog/$1/$2.shtml   [NC]

또한 일부 플래그는 RewriteCond에도 적용됩니다. 특히 NoCase.

RewriteCond %{HTTP_REFERER}        ^https?://serverfault\.com(/|$)     [NC]

"ServerFault.com"과 일치합니다.

답변2

mod_rewrite 규칙의 기본 형식과 구조는 무엇입니까?

이 점에 대해서는 sysadmin1138의 훌륭한 답변을 따르겠습니다.

정규식의 어떤 형식/특징을 확실히 이해해야 합니까?

구문 순서, 구문 일치/정규식 및 sysadmin1138에서 설명하는 RewriteRule 플래그 외에도 mod_rewrite가 HTTP 요청 헤더 및 Apache 구성을 기반으로 Apache 환경 변수를 노출한다는 언급이 있다고 생각합니다.

나는 추천하고 싶다AskApache의 mod_rewrite 디버그 튜토리얼mod_rewrite에 사용할 수 있는 포괄적인 변수 목록은 다음과 같습니다.

재작성 규칙을 작성할 때 가장 흔히 발생하는 실수/함정은 무엇입니까?

RewriteRule의 대부분의 문제는 PCRE 구문에 대한 오해/특수 문자를 적절하게 이스케이프 처리하지 못하거나 일치에 사용되는 변수의 내용에 대한 통찰력이 부족하여 발생합니다.

일반적인 문제 및 권장되는 문제 해결:

  • 500 내부 서버 오류-Windows 캐리지 컨트롤 제거구성 파일이 있는 경우 mod_rewrite가 활성화되어 있는지 확인하십시오.IfModule이 시나리오를 피하기 위해 조건부), 지시어 구문을 확인하고, 문제가 식별될 때까지 지시어를 주석 처리하세요.
  • 루프 리디렉션- RewriteLog 및 RewriteLogLevel을 사용하고 문제가 식별될 때까지 지시어를 주석 처리합니다.

mod_rewrite 규칙을 테스트하고 확인하는 좋은 방법은 무엇입니까?

먼저, 일치시키려는 환경 변수의 내용을 살펴보십시오. PHP가 설치되어 있는 경우 애플리케이션에 다음 블록을 추가하기만 하면 됩니다.

<?php
  var_dump($_SERVER);
?>

... 그런 다음 규칙을 작성하고(바람직하게는 개발 서버에서 테스트하기 위해) Apache에서 일관되지 않은 일치 또는 활동을 기록합니다.오류 기록파일.

더 복잡한 규칙의 경우 mod_rewrite를 사용하세요.RewriteLog활동을 파일에 기록하고 설정하는 지시어RewriteLogLevel 3

내가 알아야 할 mod_rewrite 규칙이 SEO 또는 성능에 미치는 영향이 있습니까?

AllowOverride allApache는 각 요청마다 파일을 확인하고 지시문을 구문 분석해야 하므로 서버 성능에 영향을 미칩니다. .htaccess가능하다면 사이트의 VirtualHost 구성에 모든 지시문을 유지하거나 .htaccess필요한 디렉터리에 대해서만 재정의를 활성화하세요.

구글의웹마스터 가이드라인명시적으로 다음과 같이 명시합니다. "사용자를 속이거나 사용자에게 표시하는 것과 다른 콘텐츠를 검색 엔진에 제공하지 마십시오. 이는 일반적으로 '클로킹'이라고 합니다." - 검색 엔진 로봇을 필터링하는 mod_rewrite 지시어를 생성하지 마세요.

검색 엔진 로봇은 1:1 콘텐츠:URI 매핑을 선호합니다(이는 콘텐츠에 대한 링크 순위 지정의 기초입니다). 임시 리디렉션을 생성하기 위해 mod_rewrite를 사용하거나 여러 URI에서 동일한 콘텐츠를 제공하는 경우표준 URIHTML 문서 내에서.

mod_rewrite가 작업에 적합한 도구처럼 보이지만 그렇지 않은 일반적인 상황이 있습니까?

이는 그 자체로 큰(그리고 잠재적으로 논쟁의 여지가 있는) 주제입니다. 사례별로 사용을 해결하고 질문자가 제안된 해결 방법이 자신의 요구에 적합한지 여부를 결정하도록 하는 것이 더 좋습니다(IMHO).

몇 가지 일반적인 예는 무엇입니까?

AskApache의 mod_rewrite 요령과 팁정기적으로 나타나는 거의 모든 일반적인 사용 사례를 다루지만 특정 사용자에 대한 "올바른" 솔루션은 사용자 구성 및 기존 지시어의 정교함에 따라 달라질 수 있습니다. 따라서 일반적으로 어떤 것이 무엇인지 확인하는 것이 좋습니다.다른mod_rewrite 질문이 나타날 때마다 사용자가 지정하는 지시문).

답변3

많은 관리자/개발자와 마찬가지로 저는 수년 동안 복잡한 재작성 규칙과 싸워왔고 기존 Apache 문서가 마음에 들지 않았기 때문에 mod_rewrite실제로 어떻게 작동하고 나머지 Apache와 상호 작용하는지 파악하기 위해 개인 프로젝트로 결정했습니다. 그래서 지난 몇 달 동안 저는 strace이 모든 것을 처리하기 위해 소스 코드를 자세히 살펴보는 테스트 사례를 계측해 왔습니다 .

규칙 재작성 개발자가 고려해야 할 몇 가지 주요 설명은 다음과 같습니다.

  • 재작성의 일부 측면은 서버 구성, 가상 호스트, 디렉터리, .htaccess 처리에 공통됩니다.하지만
  • PerDir( ) 처리와 달리 루트 구성(서버 구성, 가상 호스트 및 디렉터리)의 일부 처리는 매우 다릅니다 .htaccess.
  • 더 나쁜 것은 PerDir 처리가 거의 무차별적으로 INTERNAL REDIRECT 순환을 트리거할 수 있기 때문에 루트 구성 요소는 그러한 PerDir 처리가 이를 트리거할 수 있다는 것을 인식하도록 작성되어야 합니다.

이 때문에 재작성 사용자 커뮤니티를 두 가지 범주로 나누고 완전히 별개로 취급해야 한다고 말하고 싶습니다.

  • Apache 구성에 대한 루트 액세스 권한이 있는 사용자. 이들은 일반적으로 애플리케이션 전용 서버/VM을 사용하는 관리자/개발자이며 여기서 메시지는 매우 간단합니다. .htaccess가능하면 파일을 사용하지 마십시오. 서버 또는 가상 호스트 구성에서 모든 작업을 수행하십시오. 개발자가 디버깅을 설정할 수 있고 rewrite.log 파일에 액세스할 수 있으므로 디버깅이 비교적 쉽습니다.

  • 공유 호스팅 서비스(SHS) 사용자.

    • 이러한 사용자가지다.htaccess대안이 없기 때문에 / Perdir 처리를 사용하십시오 .
    • 더 나쁜 것은 이러한 사용자의 기술 수준(mod_rewrite의 정규식 기반 래더 논리를 사용하는 한)은 일반적으로 숙련된 관리자보다 훨씬 낮습니다.
    • Apache와 호스팅 공급자는 디버깅/진단 지원을 제공하지 않습니다. 유일한 진단 정보는 성공적인 리디렉션, 즉 잘못된 URI로의 리디렉션입니다. 또는 404/500 상태 코드. 이로 인해 그들은 혼란스럽고 무기력해졌습니다.
    • Apache는 이 사용 사례에서 재작성이 작동하는 방식을 설명하는 데 매우 약합니다. 예를 들어 어떤 PerDir 파일이 선택되었는지, 왜 선택되었는지에 대한 명확한 설명을 제공하지 않습니다 .htaccess. PerDir 사이클링의 복잡성과 이를 방지하는 방법은 설명하지 않습니다.

아마도 세 번째 커뮤니티가 있을 수 있습니다. SHS 제공업체의 관리 및 지원 직원은 결국 두 진영 모두에 발을 들여 놓고 위의 결과를 겪어야 합니다.

나는 몇 개의 기사 스타일의 블로그 게시물을 작성했습니다(예:.htaccess 파일에서 다시 쓰기 규칙을 사용하는 방법에 대해 자세히 알아보세요.) 여기에는 이 게시물을 짧게 유지하기 위해 여기서 반복하지 않을 많은 세부 사항이 포함되어 있습니다. 저는 자체 공유 서비스를 보유하고 있으며 일부 전용 및 VM FLOSS 프로젝트를 지원하고 있습니다. SHS 계정의 테스트 수단으로 표준 LAMP VM을 사용하기 시작했지만 결국에는 적절한 미러 VM을 수행하는 것이 더 낫다는 것을 알았습니다(설명됨).여기).

그러나 관리자 커뮤니티가 사용자를 지원하는 방식에 관해서는 다음을 .htaccess개발하고 제공해야 한다고 생각합니다.

  • PerDir 처리에서 다시 쓰기 시스템이 실제로 작동하는 방식에 대한 일관된 설명
  • .htaccess재작성 규칙 작성 방법에 대한 일련의 지침/모범 사례
  • W3C HTML 파서와 유사한 간단한 웹 기반 재작성 스크립트 파서이지만 이를 통해 사용자는 테스트 URI 또는 ​​동일한 테스트 벡터를 입력하고 재작성 논리 흐름에 대한 즉각적인 로그를 얻을 수 있습니다.
  • 규칙에서 내장된 진단을 얻는 방법에 대한 힌트(예:

    • 역참조($N 또는 %N)를 확장하여 대상 스크립트에 대한 진단으로 사용할 수 [E=VAR:EXPR]있다는 사실을 활용합니다 .EXPR
    • 전체 재작성 구성표가 작동하도록 [OR],[C],[SKIP] 및 [L] 플래그를 사용하여 재작성 규칙을 국소적으로 주문하는 경우없이내부 리디렉션을 활용해야 하는 경우 모든 루핑 번거로움을 피하기 위해 다음을 규칙 1로 추가할 수 있습니다.

      RewriteCond %{ENV:REDIRECT_STATUS} !=""
      RewriteRule .  -  [L]
      

답변4

재작성 규칙을 작성할 때 가장 흔히 발생하는 실수/함정은 무엇입니까?

정말 쉬운 함정은 명백한 경로를 변경하는 URL을 다시 작성할 때입니다(예: 에서 /base/1234/index.html) /base/script.php?id=1234. 클라이언트는 스크립트 위치에 대한 상대 경로가 있는 이미지나 CSS를 찾을 수 없습니다. 이 문제를 해결하기 위한 다양한 옵션은 다음에서 찾을 수 있습니다.이 자주 묻는 질문.

관련 정보