오작동 

mod_rewrite가 무엇인가요? 파일 확장자 변경에 대한 이전 버전과의 호환성. URL에서 디렉토리 디렉토리 제거

.htaccess 지시문에 대한 전체 지원이 포함되어 있습니다...

도메인 갱신 199-00 RUR

링크 변환 규칙:

.htaccess의 하위 디렉터리에 mod_rewrite 모듈 지시어가 없으면 모든 변환 규칙은 상위 디렉터리에서 상속됩니다.

.htaccess 파일에 mod_rewrite 모듈 지시문이 있으면 아무것도 상속되지 않으며 기본 상태는 웹 서버의 기본 구성 파일과 동일하게 설정됩니다(기본값은 "off"). 따라서 특정 디렉터리에 대한 변환 규칙이 필요한 경우 특정 디렉터리에 대한 .htaccess에 "RewriteEngine on" 지시문을 다시 한 번 삽입해야 합니다.

상위 디렉터리에서 규칙을 상속하고 이 디렉터리에만 해당하는 새 규칙을 추가하는 경우 시작 부분에 "RewriteEngine on"을 설정해야 하며 마지막 지시문은 서버에 계속에 대해 알립니다.

웹 도메인을 접착하려면

www를 완전히 제거하고 www가 없는 도메인(http://site, 즉 주소 표시줄에 www가 있는 도메인은 절대 존재하지 않음 - http://www.site)을 병합하려면 다음이 필요합니다. 다음 코드를 사용하려면 :

RewriteEngine 켜기

RewriteCond %(HTTP_HOST) ^www\.site

RewriteRule ^(.*)$ http://site/$1

Htaccess 리디렉션 - 301 리디렉션 - "문서가 영원히 이동되었습니다"는 이 문제를 쉽게 해결합니다.

반대의 경우 - www가 없는 사이트(http://site)를 www(http://www.site - 즉 URL에서만 사용)와 병합하려면 다음 위치에 있는 .htaccess 코드를 사용해야 합니다. 도메인 루트:

RewriteEngine 켜기

RewriteCond %(HTTP_HOST) ^사이트

RewriteRule ^(.*)$ http://www.site/$1

우리는 우리에게 전송된 구성(setting.htaccess "/" - 슬래시)을 대중에게 공개하고 마지막에 이를 대체하고 강제로 제거합니다.

URL 끝에서 슬래시를 제거하고, .htaccess URL 줄 끝에서 슬래시를 제거합니다 - 링크

RewriteEngine 켜기

RewriteCond %(REQUEST_FILENAME) !-d # 디렉토리가 아닙니다

RewriteCond %(REQUEST_URI) ^(.+)/$ # 끝에 점으로 끝남

RewriteRule ^(.+)/$ /$1 # URL 끝(마지막 문자 뒤)에서 슬래시를 제거합니다.

URL 끝에 슬래시를 추가하고, htaccess는 URL 줄 끝에 슬래시를 추가합니다. - 링크

RewriteEngine 켜기

RewriteCond %(REQUEST_FILENAME) !-f # 파일이 아닙니다

RewriteCond %(REQUEST_URI) !(.*)/$ # 끝에 점으로 끝나지 않습니다.

RewriteRule ^(.*[^/])$ $1/ # 설정 - URL 끝에 슬래시 추가 - 마지막 문자 뒤에

RewriteCond %( REMOTE _ USER ) !=""

RewriteCond /home/(%(REMOTE_USER)) -d

RewriteRule (.*) /home/%1/$1

요청된 파일을 찾아야 하는 /home/net/storag1 및 /home/net/storage2 두 개의 디렉터리가 있습니다.

RewriteCond /home/net/storage1/%(REQUEST_FILENAME) -f

RewriteRule (.+) /home/net/storage1/$1 [L]

RewriteCond /home/net/storage2/%(REQUEST_FILENAME) -f

RewriteRule (.+) /home/net/storage2/$1 [L]

업무시간 동안 웹사이트 접속을 차단합니다:

>1000

RewriteCond %(TIME_HOUR)%(TIME_MIN)<1900

RewriteRule.* - [F]

특정 사용자 에이전트를 사용하여 사용자를 리디렉션 - 브라우저를 특정 버전의 사이트로 리디렉션(예: iPhone에서 액세스하는 경우) - 사이트의 특수 모바일 버전이 있는 하위 도메인으로 사용자를 리디렉션:

RewriteEngine 켜기

RewriteRule .* http://iphone.site/ [R]

또는 하위 도메인이 아닌 /iPhone-versia/ 사이트의 특수 디렉터리로 리디렉션하는 경우 .htaccess 코드는 다음과 같습니다.

RewriteEngine 켜기

RewriteCond %(HTTP_USER_AGENT) 아이폰

RewriteCond %(REQUEST_URI) !^/iPhone-version/

RewriteRule .* /iPhone 버전/ [R]

이 경우 우리는 리소스에 액세스할 때 모든 브라우저에서 전송되는 전역 변수 HTTP 헤더 "User-Agent"를 사용했습니다(일부 브라우저의 이 헤더는 어떤 값으로든 변경할 수 있지만 99%에서는 아무도 이렇게 하지 않습니다. 예를 들어, 여러 사이트가 1마일을 구성하기 때문에 인터넷 서핑의 편안함이 줄어듭니다. 각 브라우저는 HTML5, CSS 및 기타 표준 사양의 특정 구현을 고려하여 각 브라우저에 대한 사이트 디자인을 설계합니다. 차이점.

iPhone 브라우저에는 다음과 같은 "User-Agent" 값이 있습니다.

Mozilla/5.0(iPhone; U; Mac OS X와 ​​같은 CPU; ru)

AppleWebKit/420+(KHTML, like Gecko) 버전/3.1 모바일/1C25 Safari/419.5

낯선 사람을 위해 홈 디렉토리 리디렉션

설명:

요청한 사용자가 로컬 도메인 ourdomain.com에 속하지 않는 경우 홈 디렉터리 URL을 다른 웹 서버 www.somewhere.com으로 리디렉션하려고 합니다. 이것은 때때로 가상 호스트의 맥락에서 사용됩니다.

리디렉션 규칙은 다음과 같습니다.

존재하지 않는 URL을 다른 웹 서버로 리디렉션

설명:

URL 재작성에 관해 자주 묻는 일반적인 질문은 존재하지 않는 요청을 서버 A에서 서버 B로 리디렉션하는 방법입니다. 이는 일반적으로 Perl의 ErrorDocument CGI 스크립트를 통해 수행되지만 mod_rewrite 모듈을 사용하는 솔루션이 있습니다. 그러나 이는 ErrorDocument CGI 스크립트를 사용하는 것보다 리소스를 덜 소모한다는 점에 유의하십시오!

첫 번째 솔루션은 성능은 더 뛰어나지만 유연성이 낮고 오류 방지 기능이 떨어집니다.

RewriteEngine 켜기

RewriteCond /your/docroot/%(REQUEST_FILENAME) !-f

여기서 문제는 이것이 DocumentRoot 내부에 있는 페이지에서만 작동한다는 것입니다. 더 많은 조건을 추가할 수 있지만(예: 홈 디렉터리 관리 등) 더 나은 옵션이 있습니다.

RewriteEngine 켜기

RewriteCond %(REQUEST_URI) !-U

RewriteRule ^(.+) http://webserverB.dom/$1

이는 mod_rewrite에 있는 미리보기 URL 확인 기능을 사용합니다. 결과적으로 모든 유형의 URL에 대해 작동하며 안전합니다. 그러나 각 요청에 대해 둘 이상의 내부 하위 요청이 작성되므로 웹 서버 성능이 저하됩니다. 따라서 웹 서버에 강력한 프로세서가 있는 경우 이 옵션을 사용하십시오. 시스템 속도가 느린 경우 첫 번째 또는 더 나은 ErrorDocument CGI 스크립트를 사용하세요.

시간에 따라 리디렉션

설명:

시간에 민감한 콘텐츠와 같은 트릭의 경우 많은 웹마스터가 여전히 특수 페이지로 리디렉션되는 CGI 스크립트를 사용합니다. mod_rewrite를 통해 어떻게 이를 수행할 수 있나요?

리디렉션 조건에는 TIME_xxx라는 변수가 많이 있습니다. 비교를 위한 특수 사전 편찬 샘플과 함께 STRING 및 =STRING을 사용하면 시간에 따른 리디렉션을 수행할 수 있습니다.

RewriteEngine 켜기

RewriteCond %(TIME_HOUR)%(TIME_MIN) >0700

RewriteCond %(TIME_HOUR)%(TIME_MIN)<1900

RewriteRule ^foo\.html$ foo.day.html

RewriteRule ^foo\.html$ foo.night.html

07:00부터 19:00까지 foo.html URL을 요청하면 foo.day.html의 내용을 반환하고, 나머지 시간에는 foo.night.html의 내용을 반환합니다. 어느 페이지에나 멋진 기능입니다...

콘텐츠 관리 - 이전 버전에서 새로운 버전으로(내부)

설명:

최근에 bar.html 페이지의 이름을 foo.html로 변경했으며 이제 이전 URL을 이전 버전과의 호환성을 위해 사용할 수 있도록 만들고 싶다고 가정해 보겠습니다. 실제로 우리는 이전 URL을 사용하는 사용자가 페이지 이름이 변경되었다는 사실조차 알지 못하기를 원합니다.

다음 지시문을 사용하여 내부 리디렉션을 통해 이전 URL을 새 URL로 리디렉션합니다.

RewriteEngine 켜기

RewriteBase /~quux/

RewriteRule ^foo\.html$ bar.html

오래된 것에서 새로운 것으로(외부)

설명:

최근에 페이지 bar.html의 이름을 foo.html로 변경했으며 이제 이전 URL을 이전 버전과의 호환성을 위해 사용할 수 있도록 만들고 싶다고 다시 가정해 보겠습니다. 그러나 이번에는 이전 URL을 사용하는 사용자가 이 새 URL을 인식하기를 원합니다. 브라우저의 주소 표시줄도 변경되어야 합니다.

우리는 브라우저(주소 표시줄)의 변경으로 이어지는 새 URL로의 HTTP 리디렉션을 사용하며 사용자에게는 다음과 같이 표시됩니다.

RewriteEngine 켜기

RewriteBase /~quux/

RewriteRule ^foo\.html$ bar.html [R]

브라우저 종속 콘텐츠

설명:

때로는 중요한 최상위 페이지의 경우 브라우저별 콘텐츠를 제공해야 하는 경우도 있습니다. 우선, 최신 버전의 Netscape용 정식 버전, Lynx 브라우저용 최소 버전, 기타 모든 브라우저용 중간 버전을 발행해야 합니다.

브라우저는 이 형식으로 해당 유형을 표현하지 않기 때문에 콘텐츠 협상을 사용할 수 없습니다. 대신 "User-Agent" HTTP 헤더를 사용해야 합니다. 다음 조건은 다음을 수행합니다. HTTP 헤더 "User-Agent"가 "Mozilla/3"으로 시작하는 경우 foo.html 페이지가 foo.NS.html로 변환되고 리디렉션이 중지됩니다. 브라우저가 Lynx 또는 Mozilla 버전 1 또는 2인 경우 URL은 foo.20.html이 됩니다. 다른 모든 브라우저는 foo.32.html 페이지를 수신합니다. 이는 다음 지시문 세트를 사용하여 수행됩니다.

RewriteCond %(HTTP_USER_AGENT) ^Mozilla/3.*

RewriteRule ^foo\.html$ foo.NS.html [L]

RewriteCond %(HTTP_USER_AGENT) ^Lynx/.*

RewriteCond %(HTTP_USER_AGENT) ^Mozilla/.*

RewriteRule ^foo\.html$ foo.20.html [L]

RewriteRule ^foo\.html$ foo.32.html [L]

동적 거울

설명:

원격 호스트에 멋진 페이지가 있고 이를 네임스페이스(사이트)로 가져오고 싶다고 가정해 보겠습니다. FTP 서버의 경우 로컬 시스템의 원격 데이터 복사본에 대한 업데이트를 실제로 관리하는 미러 프로그램을 사용합니다. 웹 서버의 경우 HTTP를 통해 유사한 작업을 수행하는 webcopy 프로그램을 사용할 수 있습니다. 그러나 이 두 기술 모두에는 한 가지 주요 단점이 있습니다. 즉, 이 프로그램을 실행할 때마다 로컬 복사본이 항상 최신 상태로 유지된다는 것입니다. 이 프로그램을 실행하는 빈도에 관계없이 복사본이 완전히 일치해야 미러가 정적이 아닌 경우 훨씬 더 좋습니다. 대신 필요할 때 자동 데이터 업데이트(원격 서버의 데이터 업데이트)가 가능한 동적 미러가 필요합니다.

이 기능을 제공하기 위해 프록시 처리량 옵션([P] 플래그)을 사용하여 원격 페이지 또는 심지어 완전히 원격 사이트를 웹 공간에 표시합니다.

RewriteEngine 켜기

RewriteBase /~quux/

RewriteRule ^hotsheet/(.*)$ http://www.tstimpreso.com/hotsheet/$1 [P]

RewriteEngine 켜기

RewriteBase /~quux/

RewriteRule ^usa-news\.html$ http://www.quux-corp.com/news/index.html [P]

역방향 동적 미러

설명:

RewriteEngine 켜기

RewriteCond /mirror/of/remotesite/$1 -U

RewriteRule ^http://www\.remotesite\.com/(.*)$ /mirror/of/remotesite/$1

정역학에서 동역학으로

설명:

눈에 띄지 않는 방식으로 정적 페이지 foo.html을 동적 버전 foo.cgi로 어떻게 변환할 수 있습니까? 브라우저나 사용자 모두 이를 알아차리지 못하도록 합니다.

우리는 단순히 URL을 CGI 스크립트로 리디렉션하고 실제로 CGI 스크립트로 작동하도록 MIME 유형을 조정합니다. 따라서 /~quux/foo.html에 대한 요청은 내부적으로 /~quux/foo.cgi에 대한 호출로 이어집니다.

RewriteEngine 켜기

RewriteBase /~quux/

RewriteRule ^foo\.html$ foo.cgi

즉각적인 콘텐츠 재생성

설명:

이는 실제로 시작된 페이지를 위한 것입니다. 동적으로 생성되었지만 정적으로 유지 관리되는 페이지, 즉 페이지는 순전히 정적 페이지(파일 시스템에서 읽은 다음 요청 시 제공)로 제공되어야 하지만 파일 시스템에 없는 경우 웹 서버에서 동적으로 생성해야 합니다. 이렇게 하면 누군가(또는 스케줄러)가 정적 콘텐츠를 제거하지 않는 한 정적으로 제공되는 CGI 생성 페이지를 가질 수 있습니다. 이 경우 내용이 업데이트됩니다.

이는 다음 지시문 세트를 사용하여 수행됩니다.

RewriteCond %(REQUEST_FILENAME) !-s

RewriteRule ^page\.html$ page.cgi

여기서 page.html에 대한 요청은 page.html이 아직 누락되었거나 크기가 0인 경우 해당 page.cgi가 내부적으로 실행되도록 합니다. 여기서 중요한 점은 page.cgi가 (자체 STDOUT 외에도) 출력을 page.html 파일에 기록하는 일반 CGI 스크립트라는 것입니다. 이것을 한 번 실행하면 서버는 데이터를 page.html로 전달합니다. 웹마스터가 콘텐츠를 업데이트하고 싶을 때 간단히 page.html을 삭제합니다(보통 cronjob 사용).

방문하는 웹 브라우저에서 결정된 언어에 따른 리디렉션

설명:

Htaccess 파일은 특정 언어를 사용하는 방문자를 관련 콘텐츠로 정의한 페이지로 리디렉션합니다.

필요한 자연어(예: zh-중국어)는 그대로 두고 http://site/doc/additional_material/index.php 대신 페이지를 넣습니다.

RewriteEngine 켜기

RewriteCond %(HTTP:Accept-Language) (aa|ab|af|am|ar|as|ay|az|ba|be|bg|bh|bi|bn|bo|br|ca|co|cs|cy| da|de|dz|el|en|eo|es|et|eu|fa|fi|fj|fo|fr|fy|ga|gd|gl|gn|gu|ha|hi|hr|hu|hy| ia|ie|ik|in|is|it|iw|ja|ji|jw|ka|kk|kl|km|kn|ko|ks|ku|ky|la|ln|lo|lt|lv|mg| mi|mk|ml|mn|mo|mr|ms|mt|my|na|ne|nl|no|oc|om|또는|pa|pl|ps|pt|q|rm|rn|ro|ru| rw|sa|sd|sg|sh|si|sk|sl|sm|sn|so|sq|sr|ss|st|su|sv|sw|ta|te|tg|th|ti|tk|tl| tn|to|tr|ts|tt|tw|uk|ur|uz|vi|vo|wo|xh|yo|zh|zu)

RewriteRule ..php

PR 및 TIC가 포함된 최근 출시된 도메인:

가장 큰 호스팅 및 도메인 등록 기관인 http://reg.ru 서비스를 사용하면 이전 관리자가 최근에 출시한 도메인 이름 등록을 신청할 수 있습니다. 릴리스된 도메인은 TIC 및 PR 지표가 높은 경우가 많으며 획득에 흥미로울 수 있습니다.

TIC가 포함된 domains.RU 출시:
 사용 가능한 프리미엄 도메인:

정보량: 바이트

리디렉션, 및를 사용하여 웹 사이트에서 CNC를 설정하고 기사 URL에 키워드를 삽입하는 경우 이 기사에 설명된 모든 지시문은 일반적으로 사이트 루트에 있는 .htaccess 파일에 기록되지만 일부 cms에서는 그렇지 않습니다. 거의 모든 폴더에 있지만 완전히 다른 이야기입니다 ...

다음은 이 모듈을 사용하는 5가지 예입니다.

1) “product.php?id=12”를 “product-12.html”로 변환합니다.

이는 .php 확장자가 브라우저의 주소 표시줄에서 숨겨지고 동적 URL(물음표 "?" 포함)이 정적 주소로 변환되는 간단한 리디렉션입니다.

RewriteEngine 켜기
RewriteRule ^product-(+)\.html$ product.php?id=$1

2) “product.php?id=12”를 “product/ipod-nano/12.html”로 변경합니다.

SEO 전문가들은 항상 URL에 주요 키워드를 표시할 것을 제안합니다. 예를 들어 URL에서 제품 이름을 볼 수 있습니다.

RewriteEngine 켜기
RewriteRule ^product/(+)/(+)\.html$ product.php?id=$2

3) www URL이 없는 주소를 www가 있는 주소로 리디렉션 - 리디렉션

브라우저에 yahoo.com을 입력하면 www.yahoo.com으로 리디렉션됩니다. 사이트에서 동일한 작업을 수행하려면 .htaccess 파일에 다음 코드를 추가하세요.

RewriteEngine 켜기
RewriteCond %(HTTP_HOST) ^optimaxwebsolutions\.com$
RewriteRule(.*) http://www.optimaxwebsolutions.com/$1

물론 사이트 URL을 원하는 대로 변경하세요. 왜 그러한 리디렉션을 수행합니까? www가 있거나 없는 검색 엔진에 의한 사이트 중복을 피하기 위해.

4) “yoursite.com/user.php?username=xyz”를 “yoursite.com/xyz”로 변경합니다.

.htaccess 파일에 다음 줄을 추가합니다.

RewriteEngine 켜기
RewriteRule ^(+)$ user.php?username=$1
RewriteRule ^(+)/$ user.php?username=$1

5) 새 하위 도메인 또는 폴더로 도메인 리디렉션.

사이트를 다시 디자인했고 업데이트된 사이트가 사이트 루트의 "새" 폴더에 있다고 가정해 보겠습니다. 즉, 새 사이트는 "test.com/new"에서 사용할 수 있습니다. 한 위치에서 다른 위치로 파일을 이동하는 것은 매우 지루한 과정일 수 있으므로 .htaccess 파일에 다음 줄을 추가하고 루트 폴더에 넣기만 하면 됩니다.

RewriteEngine 켜기
RewriteCond %(HTTP_HOST) ^test\.com$ RewriteCond %(HTTP_HOST) ^www\.test\.com$
RewriteCond %(REQUEST_URI) !^/new/
RewriteRule (.*) /new/$1

이제 "www.test.com"에 액세스하면 "test.com/new"에서 모든 파일을 가져옵니다.

mod_rewrite: 변수가 하나인 정적 NC 주소

그래서 이 기사에서 나는 다음 사이트에 있다고 말했습니다. PHP와 MySQL다음 형식의 주소가 있어야 합니다.

일반적으로 이러한 주소를 동적 주소라고 합니다. 이제 동적 주소를 CNC로 변환해 보겠습니다.

우리가 lis.php?id=3 V bols3.hi. 정규식의 형식은 다음과 같습니다.

RewriteRule ^페이지 이름(+)\.EXTENSION$ 실제 주소 이름.php?VARIABLE=$NUMBERING

즉, 우리의 경우 다음을 얻습니다.

RewriteRule ^bols(+)\.hi$ lis.php?id=$1

이제 주소 대신 lis.php?id=90(여기서 90은 id) 안전하게 액세스할 수 있습니다. bols90.hi.

mod_rewrite: 변수가 많은 정적 NC 주소

변수가 많은 주소를 변환해야 하는 상황을 생각해 보세요. 예를 들어, lis.php?id=345&cat=3 V bols345-3.hi. 상황은 비슷하지만 이제 두 개의 GET 변수가 사용됩니다. 대시는 구분 기호로 사용됩니다. 우리는 다음과 같은 표현을 얻습니다.

RewriteRule ^bols(+)-(+)\.hi$ lis.php?id=$1&cat=$2

그래픽적으로 변환 원리 자체는 다음과 같습니다.

mod_rewrite: 아카이브 CNC 주소

사이트의 많은 아카이브에는 주소가 있습니다. archive.php?year=2003&month=10. 우리는 그것을 아카이브/2003/10/. 우리는 다음 줄을 얻습니다:

RewriteRule ^archive/(+)/(+)\$ archive.php?year=$1&month=$2

mod_rewrite: 태그용 CNC 주소

요즘 태그는 거의 모든 블로그와 웹사이트에 존재합니다. 겨울 태그의 주소를 변경해 봅시다 — post.php?tag=겨울 V 게시물/태그/겨울/. 다음과 같은 표현이 있습니다.

RewriteRule ^posts/tags/(+)\$ posts.php?tag=$1

그런데 검색 엔진은 별도의 알고리즘을 사용하여 동적 주소가 있는 페이지를 색인화합니다. 일반적인 것과 어떻게 다른지는 모르겠지만, CNC 변환, 다시 말하지만, 일반 정적 페이지처럼 주소를 색인화해야 함을 로봇에 알리는 데 도움이 됩니다.

mod_rewrite 란 무엇입니까? mod_rewrite URL을 확인하는 데 사용되는 Apache 웹 서버 모듈입니다. 변환은 URL을 사용한 사실상 모든 작업으로 이해되어야 합니다. 이것은 매우 강력하고 동시에 매우 광범위한 기능을 갖춘 유연한 도구입니다. 이 모듈을 사용하면 거의 모든 유형의 변환을 수행할 수 있습니다. mod_rewrite를 사용하면 리디렉션 설정, URL 변경, 액세스 차단 등을 할 수 있습니다. 이는 변환 규칙, 정규식, 템플릿의 그룹화된 부분이 있는 콜백, 변환을 위한 다양한 정보 소스(서버 변수, HTTP 헤더, 시간 등)를 무제한으로 지원합니다. 이러한 기능 세트로 인해 높은 기능성과 유연성이 달성됩니다. 기본적으로 이 모듈은 비활성화되어 있습니다. 활성화하려면 .htaccess에 다음 지시문을 추가해야 합니다.

RewriteEngine 켜기
재작성베이스 /

RewriteEngine 켜기- 지시어는 모듈을 활성화합니다.
RewriteBase— 사이트 루트에서 .htaccess 파일까지의 경로를 나타냅니다. .htaccess가 루트에 있으면 예제에서와 같이 이 매개변수를 지정해야 합니다. 내부 디렉터리에 있으면 이 디렉터리에 대한 경로를 지정해야 합니다(예: /images).

mod_rewrite 모듈의 작동 방식

모듈의 작동은 변환이 수행되는 일련의 규칙 및 조건을 기반으로 합니다. 요청을 받으면 Apache는 .htaccess 파일이 있는 위치에서 시작하는 파일 경로를 mod_rewrite에 전달하고 나머지 경로는 잘립니다. 요청이 http://some-url.com/cat/cat2/file.html로 수신되고 .htaccess가 루트에 있는 경우 mod_rewrite는 cat/cat2/file.html(선두 슬래시 없이)을 포함합니다. .htaccess가 /cat 디렉토리에 있으면 mod_rewrite에는 cat2/file.html이 포함됩니다. 다음으로 mod_rewrite는 .htaccess의 규칙을 분석하고 이러한 규칙에 따라 작동합니다. mod_rewrite는 링크나 URL에서는 작동하지 않고 일반 문자열에서는 작동한다는 점을 알아두는 것이 좋습니다. 즉, 변환해야 할 주소가 일반 문자열로 mod_rewrite에 전달되고, 이 문자열을 원하는 대로 변환할 수 있습니다. 규칙을 작성하려면 RewriteCond 및 RewriteRule이라는 두 가지 지시문이 사용됩니다(이러한 지시문은 아래에 자세히 설명되어 있습니다).​
RewriteCond— 이 지시어는 RewriteRule 변환 규칙이 작동하는 조건을 정의합니다. RewriteCond의 조건이 충족되면 RewriteRule의 규칙을 실행합니다. RewriteRule 규칙 이전에는 이러한 조건이 무제한으로 있을 수 있습니다. RewriteCond는 변환 규칙을 생성하는 데 필요한 지시문이 아니므로 누락될 수 있습니다.
RewriteRule— 변환 자체에 대한 규칙은 이미 여기에 표시되어 있으며 이는 특정 변환에 대한 유일한 규칙이어야 합니다.
.htaccess의 예:

RewriteCond %(REQUEST_URI) !.(ico|css|js|txt)$
RewriteCond %(REQUEST_FILENAME) !^/admin

RewriteCond 지시문이 RewriteRule보다 높더라도 mod_rewrite는 먼저 RewriteRule의 패턴과 문자열을 비교하고 문자열이 패턴과 일치하면 RewriteCond에서 위의 조건을 확인합니다. 조건도 일치하면 RewriteRule에 따라 변환이 발생합니다. RewriteCond 및 RewriteRule 지시문의 구문과 목적을 자세히 살펴보겠습니다.

RewriteCond

위에서 언급한 것처럼 이 지시어는 RewriteRule 지시어의 규칙이 실행되는 조건을 지정합니다. 이 지시어는 다음과 같습니다:

RewriteCond [비교_문자열] [조건] [플래그]
RewriteCond %(REQUEST_URI) !.(ico|css|js|txt)$

이 예에서는 사용자의 요청에 ico, css, js 또는 txt 확장자가 포함되지 않은 경우 조건 규칙이 충족됩니다.
비교할 문자열— 일반 텍스트 외에도 정규식, 역방향 RewriteCond 및 RewriteRule 연결, 서버 변수를 포함할 수 있습니다. 실제로 이는 서버 변수와 때로는 정규식을 사용합니다.
상태- 실제로 비교 문자열이 비교되는 내용입니다. 텍스트, 정규식 및 특수 문자를 포함할 수 있습니다.

  • "-디"— 경로의 정확성(존재 여부)과 이 경로가 디렉토리 경로인지 여부를 확인합니다.
  • "-에프"— 경로의 정확성(존재 여부)과 이 경로가 일반 파일의 경로인지 여부를 확인합니다.
  • "-에스"- -f와 동일하지만 파일 크기가 0보다 큰지 추가로 확인합니다.
  • "-엘"— 경로의 정확성(존재 여부)과 이 경로가 심볼릭 링크인지 여부를 확인합니다.
  • "-에프"— 서버의 모든 기존 액세스 제어 목록을 사용하여 비교되는 문자열이 실제 기존 파일인지 여부를 내부 하위 쿼리를 통해 확인합니다. 이는 성능에 부정적인 영향을 미치므로 주의해서 사용해야 합니다.
  • "-유"— 기존의 모든 서버 액세스 제어 목록을 사용하여 비교되는 문자열이 실제로 URL인지 여부를 내부 하위 쿼리를 통해 확인합니다. 이는 성능에 부정적인 영향을 미치므로 주의해서 사용해야 합니다.
또한 조건 앞에 논리 기호를 사용할 수 있습니다.
  • "!" - 값 반전은 비교되는 문자열이 조건 패턴과 일치하지 않아야 함을 나타냅니다.
  • "<" -어휘적으로 적습니다. 예를 들어 문자 "a"는 문자 "b", "a"보다 어휘적으로 더 작습니다.< "b".
  • ">" -어휘적으로 더.
  • "=" — 평등, 기본적으로 사용됩니다.

깃발— 추가 옵션을 지정하는 선택적 매개변수입니다(여러 개가 있는 경우 쉼표로 구분). 대괄호 안에 규칙의 끝에 표시됩니다.

  • — 대소문자를 구분하지 않습니다. 즉, 비교 줄이나 조건의 대소문자(A-Z 또는 a-z)는 중요하지 않습니다.
  • - 논리적 OR. RewriteRule 지시문 앞에 여러 RewriteCond 지시문이 있고 RewriteConds 중 하나가 일치할 때 RewriteRule의 규칙을 실행해야 하는 경우에 사용됩니다. OR 플래그가 지정되지 않은 경우 RewriteRule은 모든 RewriteCond 지시문이 일치하는 경우에만 실행됩니다.

RewriteRule

​RewriteRule은 변환 규칙, 즉 URL 변경 방법을 지정합니다. 실제로 이 지시문에는 조건이 포함되어 있으며, 일치하는 경우 변환이 수행됩니다. 이는 결과 mod_rewrite 문자열을 확인하는 템플릿입니다. 아무것도 대체할 필요가 없고 이러한 경우가 가끔 발생하는 경우 새 값에 대시를 표시해야 한다는 점은 주목할 가치가 있습니다. "-" . 개략적으로 RewriteRule은 다음과 같습니다.

RewriteRule [패턴] [새_값] [플래그]
RewriteRule ^(.*)$ /index.php [L]

견본— 소스 문자열을 비교할 내용입니다. 소스 문자열이 반드시 사용자가 요청한 문자열일 필요는 없습니다. 이전에 다른 RewriteRules에 의해 수정되었을 수 있습니다. 일반 텍스트, 정규식, 역방향 RewriteCond 및 RewriteRule 연결을 포함할 수 있습니다. 소스 줄은 .htaccess 파일에서 파일까지의 경로이며 도메인 이름은 없습니다.
새로운 의미변환 후 원래 문자열이 변경될 값입니다. 일반 텍스트, 정규식, 역방향 RewriteCond 및 RewriteRule 연결, 서버 변수를 포함할 수 있습니다.
깃발— ​추가 옵션을 지정하는 선택적 매개변수입니다(여러 개가 있는 경우 쉼표로 구분). 대괄호 안에 규칙의 끝에 표시됩니다.

  • - 리디렉션. code는 브라우저 응답 코드이고 기본값은 302(임시 이동)이므로 영구 리디렉션의 경우 코드 301을 사용합니다.
  • [에프]— URL에 대한 액세스를 차단합니다. 금지됨. 서버는 브라우저에 오류 코드 403을 반환합니다.
  • [G]— 오류 410을 반환합니다. URL이 존재하지 않습니다.
  • [피]- Apache는 다른 Apache mod_proxy 모듈을 사용하여 지정된 주소에 대한 하위 요청을 수행합니다.
  • [엘]- 마지막 규칙. 이 시점에서 URL 변환을 중지해야 함을 나타냅니다.
  • [N]— 첫 번째 규칙부터 변환 프로세스가 다시 시작됩니다. 이전에 수정된 문자열이 사용됩니다.
  • [씨]— 다음 규칙과 연결되어 규칙 체인이 생성됩니다. 규칙이 일치하지 않으면 체인의 모든 후속 규칙을 건너뜁니다.
  • — 규칙은 쿼리에 대해서만 트리거되고 하위 쿼리는 무시됩니다.
  • [티]— 파일의 MIME 유형을 강제로 지정합니다.
  • - 대소문자를 무시합니다.
  • — 쿼리 문자열을 바꾸는 대신 보완합니다. 이 플래그는 %(QUERY_STRING) 변수에서 GET 매개변수로 작업할 때 매개변수를 잃지 않도록 사용해야 합니다. 이 플래그를 지정하지 않으면 %(QUERY_STRING)의 데이터가 RewriteRule의 매개변수로 완전히 대체됩니다. 플래그가 지정되면 %(QUERY_STRING)의 시작 부분에 새 매개변수가 추가됩니다.
  • — 특수 문자를 해당 16진수로 변환하는 것을 금지합니다.
  • — 변환을 중지하고 다른 지시문(Alias, ScriptAlias, Redirect 등)의 처리를 위해 문자열을 전달합니다.
  • [에스]— 다음 규칙을 건너뜁니다. S=N 형식으로 여러 규칙을 지정할 수 있습니다. 여기서 N은 규칙 수입니다.
  • — 환경 변수를 설정합니다. 여기서 VAR은 변수 이름이고 VAL은 해당 값입니다. 값은 RewriteCond 및 RewriteRule 또는 텍스트의 반대일 수 있습니다.
  • — 브라우저에 쿠키를 설치합니다. NAME - 쿠키 이름, VAL - 값, 도메인 - 도메인 이름, 수명 - 수명(선택 사항), 경로 - 이 쿠키가 유효한 경로, 기본값은 "/", 보안 - 1 또는 true로 설정하면 쿠키가 유효합니다. https(보안) 연결에서만 httponly - 1 또는 true로 설정하면 JavaScript에서 쿠키를 사용할 수 있습니다.

RewriteCond 및 RewriteRule 피드백

피드백은 문자 그룹을 사용하는 기능입니다(괄호로 묶음). "()" ) 후속 대체를 위해. 예를 들어, 대괄호 안에 특정 정규식을 지정하면 많은 수의 주소를 포함할 수 있습니다.
$N— RewriteRule 지시문 템플릿의 문자 그룹을 사용할 수 있습니다.
%N— RewriteCond 지시문 템플릿의 문자 그룹을 사용할 수 있습니다.
두 경우 모두 "N" 기호 대신 1부터 9까지의 숫자가 사용됩니다.
실제로는 다음과 같습니다. 간단한 예를 살펴보겠습니다.
http://some-url.com/cat1/cat2/cat3/cat4/page.html이라는 특정 중첩된 주소가 있습니다. http://some-url.com/cat1/cat2/cat3/cat4/page.html 페이지를 http://some-url.com/page.html에서 사용할 수 있도록 만들고 싶지만 페이지 외에도 .html, 새 주소에서도 사용할 수 있는 html 확장자를 가진 다른 파일이 많이 있습니다. 이 문제는 매우 간단하게 해결할 수 있습니다.

RewriteRule ^cat1/cat2/cat3/cat4/(.*).html$ $1.html

이제 http://some-url.com/page.html 주소에 접속하면 http://some-url.com/cat1/cat2/cat3/cat4/page.html 주소의 정보가 출력되며, http://some-url.com/*.html과 같은 모든 주소에 적용됩니다. 같은 방식으로 "%N"을 사용하면 RewriteCond에 대한 템플릿의 문자 그룹을 대체할 수 있습니다. 이 예에서는 $1 대신 템플릿의 괄호 안에 있는 문자 그룹이 대체됩니다.

서버 변수

서버 변수에는 규칙을 작성하는 데 사용할 수 있고 사용해야 하는 많은 유용한 정보가 포함될 수 있습니다. 다음은 이러한 변수의 목록입니다.
HTTP_USER_AGENT— 사용자의 브라우저 및 OS에 대한 정보를 제공합니다. 사용자가 사이트를 방문하면 사용자 에이전트가 전송됩니다. 이는 실제로 사이트에 액세스하는 데 사용되는 소프트웨어를 의미합니다.
HTTP_REFERER— 사이트로 전환된 페이지의 주소입니다.
HTTP_쿠키— 브라우저에서 보낸 쿠키 목록입니다.
HTTP_FORWARDED— 전환이 발생한 페이지의 주소입니다. HTTP_REFERER와 큰 차이를 느끼지 못했습니다.
HTTP_HOST— 서버(사이트) 주소.
HTTP_수락- 수신하려는 문서 유형에 따라 고객이 원하는 사항입니다. 실제로는 다음과 같습니다. 브라우저는 수신하려는 파일 유형을 http 헤더로 서버에 보냅니다(보통 이는 이미지 및 기타 미디어 파일에 적용됨). 즉, 처리할 수 있는 파일 유형을 알려줍니다. .
REMOTE_ADDR— 방문자의 IP 주소.
원격 호스트— "host" 명령을 통해 IP 주소에 제공되는 사용자의 주소(호스트)입니다.
REMOTE_IDENT— name.host 형식의 사용자 이름입니다.
REMOTE_USER- REMOTE_IDENT와 동일하지만 사용자의 호스트를 포함하지 않습니다.
​REQUEST_METHOD— 사이트에 대한 요청 유형(GET, POST, HEAD).
SCRIPT_FILENAME— 요청된 파일 또는 주소의 전체 경로입니다.
PATH_INFO— 스크립트로 전송된 데이터입니다.
QUERY_STRING— CGI 스크립트, GET 매개변수에 대한 요청으로 전달된 문자열입니다.
AUTH_TYPE— 사용자 식별 유형.
DOCUMENT_ROOT— 서버 루트 디렉토리의 경로입니다.
SERVER_ADMIN— 서버 관리자의 이메일.
서버 이름— 호스트 명령으로 제공되는 서버 주소(이름).
SERVER_ADDR— 귀하 사이트의 IP.
서버 포트— Apache가 실행되는 포트입니다.
SERVER_PROTOCOL— http 프로토콜 버전.
서버_소프트웨어— 사용된 Apache 버전.
TIME_YEAR, TIME_MON, TIME_DAY, TIME_HOUR, TIME_MIN, TIME_SEC, TIME_WDAY, TIME- 시간.
API_VERSION—Apache 모듈 API 버전.
THE_REQUEST— 이 행에는 브라우저에서 서버로 보낸 전체 http 요청이 포함됩니다(GET /index.html HTTP/1.1). 추가 헤더는 여기에 포함되지 않습니다.
REQUEST_URI— http 헤더에서 요청된 주소입니다.
REQUEST_FILENAME— 요청된 파일의 전체 경로는 실제로 SCRIPT_FILENAME과 동일한 데이터를 포함합니다.
IS_SUBREQ— 하위 쿼리를 확인하세요. 그렇다면 대답은 참이고, 그렇지 않으면 대답은 거짓입니다.
사이트 루트에 코드가 포함된 PHP 파일을 배치하면 서버 변수 목록을 쉽게 찾을 수 있습니다.

브라우저에 이 파일의 주소를 입력하면 페이지 하단에 서버 변수에 대한 정보가 표시됩니다.

.htaccess 구성 파일은 Apache 웹 서버용 구성입니다. 대부분의 호스팅 사이트는 이 서버를 통해 작동하므로 모든 사이트에 이 파일이 있습니다. 웹마스터는 직접 변경하여 운영을 부분적으로 제어할 수 있습니다. 이번 글에서는 서버 운영 시 변경될 수 있는 지시문과 규칙을 살펴보겠습니다.

가장 중요한 .htaccess 파일은 사이트 루트에 있습니다.

해당 작업은 현재 디렉터리와 모든 하위 디렉터리에 적용됩니다. 저것들. 사이트 소유자는 전체 서버의 작업을 방해하지 않고 프로젝트 작업에만 영향을 미칠 수 있는 기회를 갖습니다. 이 파일이 없으면 메모장을 사용하여 만들 수 있습니다. 가장 중요한 것은 파일 이름이 .txt, .doc 등의 형식이 아닌 ".htaccess"여야 한다는 것입니다.

.htaccess 파일을 사용하면 301 리디렉션이 서버 수준에서 가장 자주 구성되므로 새 페이지로 이동하는 프로세스의 속도가 크게 빨라집니다. 중간 페이지를 로드할 필요가 없습니다. 또한 404 오류를 처리하는 파일을 지정합니다.

아래에서는 .htaccess를 통한 리디렉션에 대한 모든 일반적인 옵션을 살펴보고 먼저 옵션과 규칙을 숙지하겠습니다.

리디렉션 작업을 수행하려면 ReWriteEngine 모듈을 활성화해야 합니다. 이렇게 하려면 두 줄의 코드를 작성해야 합니다(가급적이면 .htaccess 파일의 맨 위에).

옵션 +FollowSymLinks RewriteEngine 켜기

mod_write 모듈 지시문을 사용하려면 .htaccess 파일 맨 위에 이 줄을 배치하세요.

또한 호스팅에서 mod_alias 모듈을 활성화해야 합니다(Redirect, RedirectPermanent 및 RedirectMatch를 지원하려면).

1. 리디렉션, RewriteRule 및 RewriteCond 규칙

1.1. 리디렉션 지시어

리디렉션 구문:

/에서 리디렉션 http://where_full_address

리디렉션은 한 페이지에서 다른 페이지로 직접 리디렉션을 설정합니다.

리디렉션 코드는 상태에 기록됩니다. 선택적 매개변수입니다. 대부분 그들은 페이지 주소의 영구적인 변경을 알리는 301을 씁니다.

"from" 페이지는 전체 사이트 주소를 표시하지 않고 슬래시 "/"로 시작하는 전체 상대 URL(즉, 사이트 루트에서)을 표시하는 형식으로 작성하는 것이 중요합니다. 리디렉션이 진행되는 페이지는 전체 내용을 작성해야 합니다. 절대 URL 페이지 주소(예: 도메인 이름과 http 또는 https 프로토콜 포함)

예를 들어

리디렉션 301 /oldpage.php http://site/newpage.php

다르게 쓰셔도 됩니다

RedirectPermanent 301 /oldpage.php http://site/newpage.php 또는 Redirect Permanent 301 /oldpage.php http://site/newpage.php

1.2. RewriteRule 지시어

RewriteRule 지시문은 전환 규칙을 설정합니다. 구문은 다음과 같습니다.

RewriteRule 패턴 대체 [코드]
  • 외부 리디렉션이 발생하면 브라우저 줄의 URL이 " "로 변경됩니다.
  • 내부 사용 - 브라우저 줄의 URL을 변경하지 않습니다 - " " 또는 "[L] "

1.3. RewriteCond 지시어

RewriteCond 지시문은 RewriteRule의 규칙이 실행되는 조건을 정의합니다.

RewriteCond 비교_문자열상태

예를 들어 이러한 용어는 사용자의 브라우저, IP 주소, 직위 등이 될 수 있습니다.

1.4. RedirectMatch 지시문

RedirectMatch 지시문은 Redirect와 유사하지만 유일한 차이점은 정규식을 작성할 수 있다는 점입니다.

RedirectMatch 시작부터 종료까지

2. .htaccess의 301 리디렉션 예

우리는 이미 기사에서 .htaccess 리디렉션을 사용하는 많은 예를 살펴보았습니다.

  • 웹사이트 주소 변경 - 기존 도메인에서 새 도메인으로 리디렉션

여기서는 아직 존재하지 않는 리디렉션에 대한 옵션을 추가하겠습니다.

2.1. 한 페이지에서 다른 페이지로 리디렉션

site.ru/cat/oldpage에서 site.ru/newpage.html로 리디렉션

RewriteRule ^cat/oldpage.* /newpage.html

또는 두 번째 옵션:

리디렉션 301 /cat/oldpage http://www.site.com/newpage.php

2.2. 모든 .htm 파일에서 .html로 리디렉션

RewriteCond %(REQUEST_FILENAME) !-f RewriteRule ^(.*)\.htm$ $1.html

또는 두 번째 옵션:

RewriteRule ^(.*)\.htm$ $1.html

2.3. 전체 디렉토리를 다른 페이지로 리디렉션

/old/ 디렉토리와 하위 디렉토리의 모든 페이지는 /new.php로 리디렉션됩니다.

RewriteRule ^old(.*)$ /new.php

2.4. URL에서 추가 슬래시 제거

예를 들어 /catalog///stranica.html 페이지에 액세스할 수 있고 열립니다. 이러한 상황을 피하고 무한한 수의 중복을 생성하지 않으려면 다음 리디렉션을 작성해야 합니다.

RewriteCond %(REQUEST_URI) ^(.*)//(.*)$ RewriteRule . %1/%2

2.5. 리디렉션 없이 다시 작성

페이지 URL을 변경하지 않고도 다른 페이지를 로드할 수 있습니다. 예를 들어 /news.html 페이지를 로드하면 주소 표시줄에 /news/happy 주소가 표시됩니다.

RewriteRule ^news/happy.* /news.html [L]

2.6. 홈페이지 주소 끝에 슬래시 추가

예를 들어, 많은 서버는 URL에 마지막 슬래시가 기록되지 않는 방식으로 작동합니다. 예를 들어 http://site.ru입니다. 아래 코드는 이 문제를 해결합니다. 사이트는 http://site.ru/에서 열립니다.

RewriteCond %(REQUEST_URI) /+[^\.]+$ RewriteRule ^(.+[^/])$ %(REQUEST_URI)/

2.7. URL에서 디렉토리 디렉토리 제거

예를 들어, 페이지에서 리디렉션하려면 site.com/directoriya/stranica.html site.com/stranica.html에서 다음을 입력해야 합니다.

RewriteRule ^directoriya/(.+)$ http://site.com/$1

또는 두 번째 옵션:

RewriteCond %(DOCUMENT_ROOT)/directoriya/$1-f RewriteRule ^(.*)$ Directoriya/$1

2.8. GET 매개변수 리디렉션

예를 들어 /?act=page&id=2 페이지에서 /page-2/로 리디렉션합니다.

RewriteCond %(QUERY_STRING) act=페이지 RewriteCond %(QUERY_STRING) id=(\d+) RewriteRule .* /page/%1/? ]

2.9. m.site.ru 사이트의 모바일 버전으로 리디렉션

이 예에서는 사용자가 모바일 장치(HTTP_USER_AGENT)에서 사이트를 열었다는 사실을 먼저 확인한 다음 사이트 주소를 m.URL로 대체합니다.

RewriteCond %(HTTP_HOST) ^(.*)$ RewriteCond %(HTTP_USER_AGENT) (?i:midp|samsung|nokia|j2me|avant|docomo|novarra|palmos|palmsource|opwv|chtml|pda|mmp|blackberry|mib|symbian|wireless|nokia|hand|mobi|phone|cdm|upb| audio|SIE|SEC|samsung|HTC|mot-|mitsu|sagem|sony|alcatel|lg|eric|vx|NEC|philips|mmm|xx|panasonic|sharp|wap|sch|rover|pocket|benq|java |pt|pg|vox|amoi|bird|compal|kg|voda|sany|kdd|dbt|sendo|sgh|gradi|jb|dddi|moto|iphone|android) RewriteRule ^$ http://m.%1

2.10. 하위 도메인에서 리디렉션

예를 들어 하위 도메인 poddomen.site.ru의 모든 페이지에서 기본 도메인 site.ru로 리디렉션해 보겠습니다.

RewriteCond %(HTTP_HOST) ^poddomen.site.ru$ RewriteRule ^(.*)$ http://site.ru%(REQUEST_URI)

3.htaccess를 사용한 다른 예

3.1. IP 주소 및 브라우저 거부

IP 주소가 172.111.222.55인 IE 브라우저를 사용하는 사용자에게는 사이트가 열리지 않습니다.

RewriteCond %(HTTP_USER_AGENT) MSIE RewriteCond %(REMOTE_ADDR) ^172\.111\.222\.55$ RewriteRule ^.*$ - [F]

3.2. 특정 파일 거부

모든 사람에 대해 비활성화_file.html 파일을 비활성화해 보겠습니다.

모두를 거부하다

3.3. 하나의 IP에서 접근 허용

하나의 IP 주소 172.111.222.55에서만 접근이 허용됩니다.

순서 거부, 허용 거부 모두 172.111.222.55에서 허용

3.4. 다른 IP로부터의 접근 거부

여러 IP 주소 172.112.222.55, 172.113.222.55, 172.114.*.*에서 사이트에 대한 액세스를 거부합니다.

순서 거부, 허용 모두 거부 172.112.222.55에서 거부 172.113.222.55에서 거부 172.114.*.*에서 거부

3.5. 큰 문자에서 작은 문자로 URL 리디렉션

URL의 모든 대문자는 소문자로 변환됩니다.

RewriteRule - RewriteRule ! - RewriteRule ^([^A]*)A(.*)$ $1a$2 RewriteRule ^([^B]*)B(.*)$ $1b$2 RewriteRule ^([^C]*)C(.* )$ $1c$2 다시 쓰기 규칙 ^([^D]*)D(.*)$ $1d$2 다시 쓰기 규칙 ^([^E]*)E(.*)$ $1e$2 다시 쓰기 규칙 ^([^F]*) F(.*)$ $1f$2 규칙 다시 쓰기 ^([^G]*)G(.*)$ $1g$2 규칙 다시 쓰기 ^([^H]*)H(.*)$ $1h$2 규칙 다시 쓰기 ^([^ I]*)I(.*)$ $1i$2 RewriteRule ^([^J]*)J(.*)$ $1j$2 RewriteRule ^([^K]*)K(.*)$ $1k$2 RewriteRule ^([^L]*)L(.*)$ $1l$2 규칙 다시 쓰기 ^([^M]*)M(.*)$ $1m$2 규칙 다시 쓰기 ^([^N]*)N(.*)$ $1n$2 다시 쓰기 규칙 ^([^O]*)O(.*)$ $1o$2 다시 쓰기 규칙 ^([^P]*)P(.*)$ $1p$2 다시 쓰기 규칙 ^([^Q]*)Q( .*)$ $1q$2 다시 쓰기 규칙 ^([^R]*)R(.*)$ $1r$2 다시 쓰기 규칙 ^([^S]*)S(.*)$ $1s$2 다시 쓰기 규칙 ^([^T] *)T(.*)$ $1t$2 RewriteRule ^([^U]*)U(.*)$ $1u$2 RewriteRule ^([^V]*)V(.*)$ $1v$2 RewriteRule ^( [^W]*)W(.*)$ $1w$2 규칙 다시 쓰기 ^([^X]*)X(.*)$ $1x$2 규칙 다시 쓰기 ^([^Y]*)Y(.*)$ $1y $2 RewriteRule ^([^Z]*)Z(.*)$ $1z$2 RewriteRule - [N] RewriteCond %(ENV:HASCAPS) TRUE RewriteRule ^/?(.*) /$1

mod_rewrite의 기본 및 기능, mod_rewrite 사용 예, 서버 변수, 플래그( RewriteRule 플래그), 리디렉션, 시간별 또는 사용자 에이전트별 액세스 차단, 리퍼러별 액세스 차단 또는 부재 시 액세스 차단.

형제 자매 여러분, 평화가 있기를 바랍니다! 노동자들의 요청에 따라 저는 오늘 Oleg라는 이름의 일종의 교육 프로그램으로 여기에 왔습니다. 오늘 우리는 먼저 mod_rewrite 기적 모듈의 기본 원리를 스스로 설명하려고 노력할 것입니다. 조건과 규칙이 어떻게 작동하는지 명확하게 이해하고 단순히 복사/붙여넣기하는 것이 아닙니다. 그럼, 시작해 볼까요...

Apache mod_rewrite 모듈은 URL 리디렉션/변환/금지를 조작하기 위한 매우 강력하면서도 복잡한 도구입니다. 이 기적 모듈을 사용하면 서버 측에서 거의 모든 URL 변환/조작을 수행할 수 있습니다.

일부 URL 조작에는 mod_rewrite와 같은 강력하고 복잡한(특히 초보자의 경우) 모듈이 필요하지 않습니다. 간단한 작업의 경우 mod_alias를 사용할 수 있습니다. "강력하다"는 단어는 URL 변환의 폭이 넓을 뿐만 아니라 다른 모듈에 비해 서버 리소스 소비가 증가한다는 것을 의미합니다.

정규식 mod_rewrite

mod_rewrite는 Perl 호환 정규 표현식( PCRE - Perl 호환 정규식). 이 기사에서는 정규식의 사용에 대해 자세히 설명하지 않습니다. IMHO, 전체 책이 이 주제를 다루고 있으며 한 기사에서 이 주제를 다루는 것은 불가능합니다.

  • 정규식의 비밀: 1부. 방언과 기능. 정규식 작성

기억해야 할 가장 중요한 점은 정규 표현식에 특수 문자( 메타 문자) 및 일반 문자( 리터럴). 주요 메타 문자는 \ / ^ $ 입니다. | ? * + () ( ) . 메타 문자는 항상 백슬래시 "\"로 이스케이프되어야 합니다. 이는 백슬래시("\\")뿐만 아니라 공백("\")에도 적용됩니다.

기억해야 할 한 가지는 mod_rewrite가 원래 PCRE( Perl 호환 정규식), 그러나 몇 가지 추가 사항이 있습니다:

  • "!조건"(조건이 충족되지 않음)
  • "<Условие " (лексически меньше условия)
  • ">조건"(어휘적으로 조건 이상)
  • "=조건"(어휘적으로 조건과 동일)
  • "-d "(디렉토리입니까)
  • "-f " (일반 파일인가요?)
  • "-s " (0이 아닌 크기의 일반 파일입니까)
  • "-l "(심볼릭 링크입니까)
  • "-F "(하위 쿼리를 통해 파일 존재 여부 확인)
  • "-U "(하위 쿼리를 통해 URL 존재 확인)

Mod_rewrite 규칙 처리 순서

mod_rewrite 규칙이 처리되는 순서는 명확하지 않습니다. mod_rewrite 규칙은 대략 다음 순서로 구성됩니다.

RewriteBase의 RewriteEngine / # 웹 기반 디렉토리가 루트가 아닌 경우 이 줄의 주석 처리를 제거합니다. # RewriteBase /you-web-base-dir RewriteCond %(what_to 비교) with_what_to 비교 [플래그] RewriteRule source_url target_url [플래그]

이제 좀 더 자세히 설명하겠습니다.

  • RewriteEngine - 하나 있어야 합니다.
  • RewriteBase - 규칙에서 상대 링크를 사용할 때 유용할 수 있지만, 상대 링크가 디렉터리의 루트를 참조하는 경우 이론적으로 이 지시어는 사용되지 않을 수 있으며 각 규칙 앞에 여러 번 사용될 수 있습니다.
  • RewriteCond - 규칙이 실행되기 전에 충족되어야 하는 조건에는 여러 가지가 있을 수 있습니다.
  • RewriteRule은 조건이 충족될 때 실행되는 규칙 자체입니다.

.htaccess 규칙이 배치되는 순서는 변환 엔진이 규칙을 특별한 순서로 처리하기 때문에 중요합니다. 한 줄씩 RewriteRule 지시어를 먼저 살펴보고 URL 패턴이 일치하는지 확인합니다( 패턴, source_url) 특정 규칙의 조건을 확인합니다( RewriteCond 지시문) 이 규칙과 관련이 있습니다. 조건( RewriteCond)는 항상 규칙( RewriteRule)! 그림에서. 다음은 mod_rewrite 규칙이 처리되는 방식입니다.

보시다시피, 현재 URL은 먼저 규칙 패턴과 비교되고, 패턴이 일치하면 조건을 확인하고, 현재 URL이 조건을 만족하면 규칙과 변환이 적용됩니다. [L] 플래그가 지정되지 않은 경우 URL은 처리를 위해 계속 진행됩니다( 마지막).

물론 추가 URL 변환이 필요하지 않은 경우에는 각 규칙에 대해 [L] 플래그를 사용해야 합니다.

mod_rewrite 변수

조건(RewriteCond) 및 규칙(RewriteRule)에서 서버 변수를 사용할 수 있습니다.

1. HTTP 헤더(RqH - 요청 헤더):

  • HTTP_USER_AGENT - 전체 헤더 줄 "User-Agent:"를 포함합니다.
  • HTTP_REFERER - 사용자가 온 주소입니다.
  • HTTP_COOKIE - 브라우저의 COOKIE 목록에 액세스합니다.
  • HTTP_FORWARDED - 프록시 또는 로드 밸런싱 서버의 IP 주소를 포함합니다.
  • HTTP_HOST - 사용자가 요청한 호스트/서버 주소(예: example.com)
  • HTTP_PROXY_CONNECTION - 연결 토큰을 포함합니다( 연결 토큰) "close" 또는 "Keep-Alive"는 클라이언트와 서버 간의 지속적인 연결을 협상하기 위한 것입니다(Connection 헤더와 유사).
  • HTTP_ACCEPT - 사용자의 브라우저/클라이언트가 지원하는 콘텐츠 협상 헤더(예: " text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 " ("유형/하위 유형", 구분됨) 쉼표로 구분합니다. 여기서 유형은 콘텐츠 유형이고 하위 유형은 유형의 구체화입니다.) Accept 헤더에 " Accept: */* "(*/*)가 포함되어 있으면 클라이언트가 모든 유형의 콘텐츠를 수락할 준비가 되었음을 의미합니다.

2. 연결 및 요청(연결 및 요청):

  • REMOTE_ADDR - 클라이언트 IP 주소;
  • REMOTE_HOST - 클라이언트 IP 주소의 DNS 이름입니다.
  • REMOTE_PORT - 현재 클라이언트 포트 번호.
  • REMOTE_USER - 승인된(서버 수단을 사용하는) 사용자의 이름을 포함합니다.
  • REMOTE_IDENT - 변수는 mod_ident 모듈이 연결되어 있고 IdentityCheck가 "on"으로 설정된 경우에만 설정되며 Ident 프로토콜 https://ru.wikipedia.org/wiki/Ident와 작동하도록 설계되었습니다.
  • REQUEST_METHOD - 요청이 이루어진 방법, GET|GET|HEAD 등.
  • SCRIPT_FILENAME - 요청된 파일의 전체 경로(예: /var/www/public_html/script_name.php)
  • PATH_INFO - 스크립트 이름 뒤, 쿼리 문자열(?) 앞에 나타나는 사용자 제공 경로를 포함합니다. 예를 들어 스크립트가 http://www.example.com/php/path_info.php/some/stuff?foo=bar URL에서 요청된 경우 $_SERVER["PATH_INFO"] 변수에는 /some/이 포함됩니다. 물건.
  • QUERY_STRING - GET 요청 문자열, 요청된 주소가 http://example.com/index.php?var=1&var=2인 경우 QUERY_STRING에는 var=1&var=2;AUTH_TYPE이 포함됩니다. - HTTP 인증이 수행되는 경우 인증 유형, 기본 또는 다이제스트일 수 있습니다.

3. 서버 내부:

  • DOCUMENT_ROOT - 사용자 홈 디렉토리의 전체 경로(예: /var/www/public_html/)
  • SERVER_ADMIN - 서버/virtual_host 관리자 데이터, 일반적으로 이메일 주소입니다.
  • SERVER_NAME - 일반적으로 ServerName 지시문에서 가져온 서버 이름입니다.
  • SERVER_ADDR - 서버 IP 주소;
  • SERVER_PORT - 서버 포트;
  • SERVER_PROTOCOL - 사용된 프로토콜 버전(예: HTTP/1.0 또는 HTTP/1.1)
  • SERVER_SOFTWARE - 서버의 이름/버전.

4. 날짜 및 시간(시스템, 날짜 및 시간):

  • TIME_YEAR - 2014년
  • TIME_MON - 월, 05
  • TIME_DAY - 07일
  • TIME_HOUR - 시간, 04(24)
  • TIME_MIN - 분, 38
  • TIME_SEC - 초, 55
  • TIME_WDAY - 요일, 3(수요일)
  • TIME - 연-월-일-시-분-초 형식(예: 20140514234534)

5. 스페셜(스페셜):

  • API_VERSION - "20051115:33" 형식
  • THE_REQUEST - GET/POST 요청의 세부정보(예: "GET /index.html HTTP/1.1")
  • REQUEST_URI - 상대 요청 URL "/index.html"
  • REQUEST_FILENAME - 해당 요청의 파일 시스템에 있는 파일 또는 스크립트에 대한 전체 로컬 경로
  • IS_SUBREQ - 하위 쿼리가 실행되면 변수에 true가 포함되고, 그렇지 않으면 false가 포함됩니다.
  • HTTPS - 켜짐/꺼짐, HTTPS가 사용되거나 사용되지 않는 경우

6. 실행 결과 변수:

  • 1달러 - 1달러, 2달러 등 (pattern1.*)이 RewriteRule의 (pattern2.*)와 일치할 때 형성됩니다.
  • %1 - %1, %2 등 (pattern1.*)이 RewriteCond의 (pattern2.*)와 일치할 때 형성됩니다.
  • HTTP 헤더에 대한 자세한 내용은 rfc2616 하이퍼텍스트 전송 프로토콜 사양 - HTTP/1.1에서 찾을 수 있습니다.

mod_rewrite 플래그

조건의 동작을 제어하려면( RewriteCond) 및 규칙( RewriteRule) mod_rewrite는 플래그 [flags]를 사용합니다.

  • [B] ( 역참조 탈출) - 특수 문자를 이스케이프(인코딩)하도록 강제합니다. 예를 들어 "RewriteRule ^search/(.*)$ /search.php?term=$1" 규칙을 사용하면 다음과 같은 검색 문자열이 포함될 수 있습니다. x & y/z” " 그리고 결과는 " search.php?term=x & y/z " 문자열이 될 것입니다. 이는 유효한 URL이 아니며 브라우저에 의해 " search.php?term=x로 변환됩니다. %20&y%2Fz= ". [B] 플래그를 사용하면 문자열이 " /search.php?term=x%20%26%20y%2Fz "로 변환됩니다. 이 예제가 작동하려면 기본적으로 httpd는 URL에서 슬래시 인코딩을 허용하지 않기 때문에 AllowEncodedSlashes를 On으로 설정해야 합니다.
  • [씨] 체인- 여러 규칙을 체인으로 결합합니다. 체인의 첫 번째 규칙이 조건을 충족하지 않으면 전체 체인이 무시됩니다.
  • 쿠키- 쿠키 형식을 설정하고 secure 및 httponly 매개변수는 true|false로 설정됩니다.
  • 폐기 경로 정보- 변환된 링크에서 PATH_INFO를 삭제합니다. 이전 변환에서 PATH_INFO가 이미 추가된 경우에 유용합니다.
  • [이자형] 환경- 변수를 설정하거나 삭제합니다.
  • [에프] 금지된- 오류 403을 반환합니다.
  • [G] 다 쓴- 오류 410을 반환합니다.
  • [시간] 매니저- 특정 파일 유형에 대한 핸들러를 강제로 설치합니다. 예를 들어 "RewriteRule !\. -" 규칙은 확장자가 없는 모든 파일이 PHP를 통해 전달되도록 강제합니다.
  • [엘] 마지막- 규칙이 마지막이고 추가 변환 프로세스가 중지됨을 나타냅니다.
  • [N] 다음- 첫 번째 규칙부터 변환 프로세스를 순서대로 시작합니다. 이 플래그는 닫힌 루프(소위 루프)로 이어질 수 있으므로 주의해서 사용하세요.
  • 노케이스- 대소문자 확인을 비활성화합니다.
  • 탈출구가없는- mod_rewrite는 일반적으로 재작성 결과에 URI 이스케이프 규칙을 적용합니다. 특수 문자(예: "%", "$", ";" 등)는 16진수( 16진수 코드) 대체(각각 "%25", "%24" 및 "%3B"). 이 플래그는 이를 금지합니다.
  • nosubreq- 하위 쿼리를 무시하고 실제/직접 쿼리에 대해서만 규칙을 실행합니다.
  • [피] 대리- Apache는 mod_proxy 소프트웨어 모듈을 사용하여 지정된 페이지에 대한 하위 요청을 실행하며 클라이언트는 이 하위 요청에 대해 아무것도 모릅니다. mod_proxy 모듈이 연결되지 않으면 오류가 발생합니다
  • 지나가 다- 변환을 중지하고 결과로 생성된 새 링크를 추가로 전달합니다.
  • qsappend- 초기 요청 매개변수를 추가합니다( 쿼리 문자열) 교체를 위해. 조회에 새 쿼리 매개변수가 포함되지 않은 경우 원래 쿼리 매개변수가 자동으로 추가됩니다. 새 매개변수가 대체에 포함된 경우 QSA 플래그가 지정되지 않으면 원래 요청 매개변수가 손실됩니다.
  • [아르 자형] 리디렉션- 브라우저에 리디렉션 명령을 반환합니다( 기본 코드는 302 - 임시 이동입니다.), 리디렉션 코드를 직접 지정할 수 있습니다(예: R=301( 코드 301 - 영구적으로 이동됨), 그러나 300-399 범위 내에 있으면 규칙이 처리되지 않습니다.
  • [에스] 건너뛰다- 이 규칙이 트리거되면 다음 규칙을 건너뜁니다. 규칙 수를 지정할 수 있습니다(예: S=2).
  • [티] 유형- 대상 파일의 MIME 유형을 강제로 적용합니다. 예를 들어, "RewriteRule \.pl$ -"인 경우 이 규칙은 Perl 스크립트를 텍스트 형식으로 표시합니다. 이는 스크립트 코드가 브라우저에 출력된다는 의미입니다.

원본의 플래그에 대해 자세히 알아보세요.

mod_rewrite에서 허용되는 프로토콜

mod_rewrite는 프로토콜 중 하나가 지정된 경우 와일드카드 URL을 외부로 정의합니다.

  • ajp:// - Apache JServ 프로토콜
  • Balancer:// - 아파치 로드 밸런서
  • ftp:// - 파일 전송 프로토콜
  • gopher:// - Gopher(프로토콜)
  • http:// - 하이퍼텍스트 전송 프로토콜
  • https:// - 하이퍼텍스트 전송 프로토콜 보안
  • ldap:// - 경량 디렉터리 액세스 프로토콜
  • nntp:// - 네트워크 뉴스 전송 프로토콜
  • ldap: - 경량 디렉터리 액세스 프로토콜
  • mailto: - mailto URI 체계
  • 뉴스: - 뉴스 프로토콜

.htaccess 및 규칙 배치 순서

.htaccess 파일에서는 이론적으로 rewrite_module과 관련된 지시문을 제외하고 지시문을 무작위로 지정할 수 있습니다. 그러나 특정 순서를 따르는 것이 좋습니다.

  1. CORE 지시어;
  2. 모듈 구성.

변환이 아닌 리디렉션을 수행하는 rewrite_module 지시어가 먼저 와야 합니다. 그렇지 않으면 요청이 변환된 후 이전 변환을 고려하지 않으면 원하는 리디렉션이 발생하지 않을 수 있습니다.

mod_rewrite 규칙의 예

mod_rewrite를 사용하여 액세스 거부

RewriteCond %(TIME_HOUR)%(TIME_MIN) >2000 RewriteCond %(TIME_HOUR)%(TIME_MIN)<0700 RewriteRule .* - [ F ] # OR RewriteCond %{TIME_HOUR} >=20 RewriteCond %(TIME_HOUR)<07 RewriteRule .* - [ F ]

이 규칙은 오후 8시부터 오전 7시까지 접근을 차단합니다. 특히 복사/붙여넣기 팬의 경우 위의 예에는 의도적인 구문 오류인 HTTP 500( 서버 오류), 이로 인해 오류 로그 RewriteRule: bad flag delimiters에 항목이 표시됩니다. 잘못된 플래그 구분 기호로 번역됨 - [ F ] 대신 [ F ] 를 사용해야 합니다. 즉, 쉼표 이외의 공백 및 기타 구분 기호는 사용하지 마세요!

2. WBSearchBot 봇이 당사 사이트에 접근하는 것을 엄격히 금지합니다.

RewriteCond %(USER_AGENT) WBSearchBot RewriteRule .* - [F] # 또 다른 옵션은 오류 403(FORBIDDEN) 대신 오류 404(NOT FOUND)를 표시하는 것입니다. RewriteCond %(USER_AGENT) WBSearchBot RewriteRule .* -

하지만 규칙을 약간 조정하면 t.s. 화살표를 다른 사람에게 전송합니다. 말하자면, 봇을 다른 사이트에 설정하면...미쳤어요!? 가서 훈련하세요... :)) (영화 "Y" 작전과 Shurik의 다른 모험에서):

RewriteRule .* http://kremlin.ru

WBSearchBot( Mozilla/5.0(호환 가능; WBSearchBot/1.1; +http://www.warebay.com/bot.html))은 다소 공격적인 봇이므로 안전하게 제거할 수 있습니다.

# 이전 HTTP 프로토콜에 대한 블록 포스트 요청... RewriteCond %(THE_REQUEST) ^POST RewriteCond %(HTTP_REFERER) !^http(s)?://(www\.|www1\.)?example.com RewriteCond %(THE_REQUEST) POST(.*)HTTP/(0 \ .9|1 \.0) RewriteCond %(HTTP_USER_AGENT) ^$ RewriteRule .* -

이전 예에서 303 See Other 응답 코드는 우연히 지정되지 않았습니다. 사실은 리디렉션 방법( 보통 GET)는 요청 방법( 예를 들어 POST), 응답 코드 301-302가 반환되면 자동 리디렉션 대신 수동 탐색 링크가 있는 페이지가 브라우저에 표시됩니다! 303 See Other 응답의 경우 요청 방식에 관계없이 GET 방식을 사용하여 자동으로 리디렉션이 수행됩니다.

4. 핫링크 보호 - 당사 이미지가 다른 사이트에 표시되는 것을 금지합니다.

# # 핫링크 보호... # http://www.htaccesstools.com/hotlink-protection/ RewriteCond %(HTTP_REFERER) !^$ RewriteCond %(HTTP_REFERER) !^http(s)?://(www\.|www1\.)?site RewriteCond %(HTTP_REFERER) !^http(s)?://( www\.)?google.com RewriteCond %(HTTP_REFERER) !^http(s)?://(www\.)?yandex.ru RewriteCond %(HTTP_REFERER) !^http(s)?://(www\ .)?subscribe.ru RewriteCond %(HTTP_REFERER) !^http(s)?://(www\.)?feedburner.com RewriteCond %(HTTP_REFERER) !^http(s)?://(www\.) ?mail.ru RewriteCond %(HTTP_REFERER) !^http(s)?://(www\.)?poisk.ru RewriteCond %(HTTP_REFERER) !^http(s)?://(www\.)?rambler .ru RewriteCond %(HTTP_REFERER) !^http(s)?://(www\.)?nigma.ru RewriteCond %(HTTP_REFERER) !^http(s)?://(www\.)?ask.com RewriteCond %(HTTP_REFERER) !^http(s)?://(www\.)?qip.ru RewriteCond %(HTTP_REFERER) !^http(s)?://(www\.)?ukr.net RewriteCond % (HTTP_REFERER) !^http(s)?://(www\.)?conduit.com RewriteCond %(HTTP_REFERER) !^http(s)?://(www\.)?tut.by RewriteCond %(HTTP_REFERER ) !^http(s)?://(www\.)?bing.com RewriteCond %(HTTP_REFERER) !^http(s)?://(www\.)?webalta.ru RewriteCond %(HTTP_REFERER) ! ^http(s)?://(www\.)?yahoo.com RewriteCond %(HTTP_REFERER) !^http(s)?://(www\.)?conduit.com RewriteRule \.(jpg|jpeg| png|gif) https://dl.dropboxusercontent.com/u/52572427 / \ Images/wrs-hotlink-deny .jpg

  • RewriteRule ^ - RewriteRule의 RewriteCond %(HTTPS) ^ - # 모든 사용자가 "www."를 사용하여 사이트에 액세스하도록 리디렉션합니다. 접두사 # (http://example.com/...은 http://www.example.com/...으로 리디렉션됩니다.)# 다음 주석을 제거합니다: RewriteCond %(HTTP_HOST) . RewriteCond %(HTTP_HOST) !^www\. RewriteRule ^ http%(ENV:protossl)://www.%(HTTP_HOST)%(REQUEST_URI) # 또는 # REDIRECT FOR /DOCS 영구 /docs 리디렉션 http://docs.example.com

    2. RSS/ATOM 피드를 FeedBurner로 리디렉션

    # 블로그 RSS/ATOM을 FeedBurner로 리디렉션... RewriteCond %(HTTP_USER_AGENT) !^.*(FeedBurner|FeedValidator) RewriteCond %(QUERY_STRING) ^option=com_content&view=featured&Itemid=()+&format=feed RewriteRule index.php http://feeds.feedburner.com/remote-shaman- 블로그? # # 포럼 RSS/ATOM을 FeedBurner로 리디렉션... # HTTP_USER_AGENT가 FeedBurner 또는 FeedValidator가 아닌 경우 RewriteCond %(HTTP_USER_AGENT) !^.*(FeedBurner|FeedValidator) # 포럼/주제/모드-주제?format=피드 # 포럼/주제/mode-latest?format=피드 # 포럼/주제/게시물?format=피드# forum/recent?format=feed RewriteCond %(QUERY_STRING) ^format=feed$ RewriteRule forum/(*/)?()+ http://feeds.feedburner.com/remote-shaman-forum?

    규칙의 각 링크 끝에는 ( RewriteRule) "?" 기호가 있습니다. 이는 요청이 리디렉션될 링크 끝에 QUERY_STRING 매개변수가 추가되지 않도록 하기 위해 필요합니다! "?" 문자를 지정하지 않으면 리디렉션은 http://feeds.feedburner.com/remote-shaman-blog?option=com_content&view=featured&Itemid=... 및 http://feeds가 됩니다. Feedburner.com /remote-shaman-forum?format=feed 각각.

    결과

    mod_rewrite는 강력한 도구이며 놀라운 일을 해낼 수 있습니다. 이는 사실입니다! 이 기사에는 예가 많지 않지만 인터넷에 많은 예가 있지만 완전한 바보를위한 스타일이 무엇인지, 왜인지에 대한 자료는 거의 없습니다. 아마도 mod_rewrite 사용에 대한 더 많은 예제가 나중에 이 페이지에 추가될 것입니다.

    이 기사에서 나는 기적 모듈 mod_rewrite의 기본 작동 원리를 완전한 바보(좋은 의미에서)와 같은 스타일로 가능한 한 명확하게 설명하려고 노력했습니다(성공했으면 좋겠습니다). IMHO, I 내 경험을 통해 0으로 무언가를 마스터하는 것이 때때로 얼마나 어려운지, 그리고 이 무언가의 마나와 원리가 일반적으로 모호한 문구와 매우 기술적인 용어로 설명될 때를 알고 있습니다.

    이 자료를 작성할 때 httpd.apache.org 사이트의 원본 마나만 사용되었습니다(복사/붙여넣기 없음). 내가 뭔가를 놓쳤거나 어딘가에 놓친 것이 있으면 댓글에 적어주세요.



질문이 있으신가요?

오타 신고

편집자에게 전송될 텍스트:

보내다