1장 - Dispatcher 개념, 패턴 및 패턴 방지

참조 및 메쉬된 콘텐츠

매시드 콘텐츠 문제

AEM에 업로드된 이미지 또는 기타 이진 파일과 달리 HTML 페이지는 독립적인 동물이 아닙니다. 그들은 떼지어 살고 하이퍼링크와 참조에 의해 서로 고도로 연결되어 있다. 간단한 링크는 무해하지만, 콘텐츠 참조에 대해 이야기할 때는 까다로워집니다. 페이지의 유비쿼터스 위쪽 탐색 또는 티저는 콘텐츠 참조입니다.

콘텐츠 참조 및 이것이 문제가 되는 이유

간단한 예를 살펴보겠습니다. 한 여행사에서 캐나다 여행을 홍보하는 웹페이지가 있다. 이 프로모션은 다른 두 페이지의 티저 섹션("홈" 페이지 및 "겨울 스페셜" 페이지)에 나와 있습니다.

두 페이지 모두 동일한 티저를 표시하므로 작성자에게 표시해야 하는 각 페이지에 대해 티저를 여러 번 생성하도록 요청하는 것은 불필요한 작업입니다. 대신 대상 페이지 "캐나다"는 티저에 대한 정보를 제공하기 위해 페이지 속성의 섹션을 예약합니다. 또는 티저를 모두 렌더링하는 URL을 제공하는 것이 더 좋습니다.

<sling:include resource="/content/home/destinations/canada" addSelectors="teaser" />

또는

<sling:include resource="/content/home/destinations/canada/jcr:content/teaser" />

AEM에서는 매력적으로 작동하지만 Publish 인스턴스에서 Dispatcher을 사용하면 이상한 일이 발생합니다.

웹 사이트를 게시했다고 상상해 보십시오. 캐나다 페이지의 제목은 "Canada"입니다. 방문자가 해당 페이지에 대한 티저 참조가 있는 홈 페이지를 요청하면 "캐나다" 페이지의 구성 요소가 다음과 같이 렌더링됩니다

홈 페이지를 into ​합니다. 홈 페이지는 Dispatcher에 의해 티저 및 파일의 헤드라인을 포함하여 정적 .html 파일로 저장됩니다.

이제 마케팅 담당자는 티저 헤드라인이 실행 가능해야 한다는 것을 알게 되었습니다. 그래서 그는 제목을 "캐나다"에서 "캐나다 방문"으로 변경하기로 결정하고 이미지도 업데이트합니다.

그는 편집된 "캐나다" 페이지를 게시하고 이전에 게시된 홈 페이지를 다시 방문하여 변경 사항을 확인합니다. 하지만 거기엔 아무 것도 바뀌지 않았어요 여전히 이전 티저가 표시됩니다. 그는 "겨울 스페셜"을 두 번 점검한다. 해당 페이지는 이전에 요청된 적이 없기 때문에 Dispatcher에 정적으로 캐시되지 않습니다. 따라서 이 페이지는 Publish에서 새로 렌더링했으며 이제 이 페이지에 새로운 "캐나다 방문" 티저가 포함됩니다.

Dispatcher이 홈 페이지에 오래된 포함된 콘텐츠를 저장

무슨 일이 있었던 거야? Dispatcher은 렌더링하는 동안 다른 리소스에서 가져온 모든 컨텐츠 및 마크업이 포함된 페이지의 정적 버전을 저장합니다.

파일 시스템 기반 웹 서버인 Dispatcher은 속도가 빠르지만 비교적 간단합니다. 포함된 리소스가 변경되는 경우 이를 인식하지 못합니다. 포함 페이지가 렌더링될 때 있던 콘텐츠에 계속 연결됩니다.

"겨울 특별 광고" 페이지가 아직 렌더링되지 않았으므로 Dispatcher에 정적 버전이 없으므로 요청 시 새로 렌더링되므로 새 티저와 함께 표시됩니다.

Dispatcher은 리소스가 변경될 때 이 리소스를 사용한 모든 페이지를 렌더링하고 플러시하는 동안 해당 리소스가 접촉하는 모든 리소스를 추적한다고 생각할 수 있습니다. 하지만 Dispatcher은 페이지를 렌더링하지 않습니다. 렌더링은 Publish 시스템에서 수행됩니다. Dispatcher은 렌더링된 .html 파일에 어떤 리소스가 들어가는지 알지 못합니다.

아직도 납득이 안 가요? "일종의 종속성 추적" ​을(를) 구현하는 방법이 있어야 한다고 생각할 수 있습니다. was ​이(가) 있습니다. Communiqué 3 AEM의 고조부는 페이지를 렌더링하는 데 사용되는 session ​에서 종속성 추적기를 구현했습니다.

요청 중에 이 세션을 통해 얻은 각 리소스는 현재 렌더링 중인 URL의 종속성으로 추적되었습니다.

그러나 의존성을 추적하는 것은 매우 비싸다는 것이 판명되었습니다. 사람들은 곧 종속성 추적 기능을 모두 끄고 한 html 페이지가 변경된 후 모든 html 페이지를 다시 렌더링하는 데 의존한다면 웹 사이트가 더 빠르다는 것을 알게 되었습니다. 게다가, 그 계획은 완벽하지 않았다 - 거기에는 많은 위험과 예외가 있었다. 리소스를 가져오기 위해 요청 기본 세션을 사용하지 않는 경우와 요청을 렌더링할 일부 도우미 리소스를 가져오기 위해 관리 세션을 사용하는 경우가 있었습니다. 이러한 종속성은 일반적으로 추적되지 않았으며 수동으로 캐시를 플러시하도록 요청하는 운영 팀에 대한 전화 문의 및 골칫거리로 이어졌습니다. 그들이 그것을 하기 위한 표준 절차를 가졌다면 당신은 운이 좋았습니다. 가는 길에 더 많은 문제가 있었지만… 회상하지 맙시다. 이것은 2005년으로 거슬러 올라갑니다. 궁극적으로 이 기능은 기본적으로 Communiqué 4에서 비활성화되었으며 후속 CQ5로 다시 전환되지 않았으며 AEM이 되었습니다.

응답형 이미지 구성 요소 작동 중

이제 사용자가 Dispatcher을 통해 페이지 및 에셋을 요청합니다. 그러면 아래 그림과 같이 Dispatcher 파일 시스템에 파일이 생성됩니다.

캡슐화된 반응형 이미지 구성 요소의 캐시된 구조

사용자가 DAM에 두 꽃 이미지의 새 버전을 업로드하고 활성화한다고 가정해 봅시다. AEM은 다음에 대한 무효화 요청에 따라 을(를) 전송합니다.

/content/dam/flower.jpg

및

/content/dam/flower-mobile.jpg

Dispatcher에 하지만 이런 요청들은 헛수고다. 콘텐츠가 구성 요소의 하위 구조 아래에 파일로 캐시되었습니다. 이러한 파일은 현재 사용되지 않지만 요청 시 계속 제공됩니다.

구조 불일치로 인해 오래된 콘텐츠 발생

이 접근법에는 또 다른 주의사항이 있다. 여러 페이지에서 동일한 flower.jpg를 사용하는 것이 좋습니다. 그러면 동일한 에셋이 여러 URL 또는 파일에 캐시됩니다.

캐시되지 않은 새 페이지가 요청될 때마다 자산은 다른 URL의 AEM에서 가져옵니다. Dispatcher 캐싱과 브라우저 캐싱을 모두 사용하지 않으면 게재 속도가 빨라집니다.

스풀러 패턴이 빛나는 위치

간단한 형식에서도 이 패턴이 유용한 한 가지 자연 예외가 있습니다. 바이너리가 DAM이 아닌 구성 요소 자체에 저장되는 경우입니다. 그러나 이 기능은 웹 사이트에서 한 번 사용된 이미지에만 유용하며 DAM에 에셋을 저장하지 않으면 에셋 관리에 어려움이 있습니다. 특정 자산에 대한 사용 라이선스가 부족하다고 상상해 보십시오. 자산을 사용한 구성 요소를 어떻게 확인할 수 있습니까?

봤지? DAM의 "M"은 Digital Asset Management에서와 같이 "Management"를 나타냅니다. 그 기능을 없애고 싶진 않군요.

결론

AEM 개발자의 관점에서 볼 때 이 패턴은 매우 우아해 보였다. 그러나 Dispatcher의 등장으로 순진한 접근으로는 충분하지 않을 것이라는 점에는 동의할 수 있을 것입니다.

일단 이것이 패턴인지 아니면 안티패턴인지 결정하는 것은 여러분에게 맡깁니다. 위에서 설명한 문제를 완화하는 방법에 대해 이미 염두에 둔 좋은 아이디어가 있으십니까? 잘됐네 그렇다면 다른 프로젝트들이 이러한 문제들을 어떻게 해결했는지 간절히 보아야 한다.

일반적인 Dispatcher 문제 해결

개요

이를 좀 더 캐시 친화적으로 구현하는 방법에 대해 살펴보겠습니다. 몇 가지 옵션이 있습니다. 때때로 당신은 최선의 해결책을 선택할 수 없습니다. 이미 실행 중인 프로젝트에 들어갔을 때 예산이 제한되어 있어 "캐시 문제"를 바로 해결할 수 있을 뿐 완전한 리팩터링을 수행하기에는 충분하지 않을 수 있습니다. 또는 예제 이미지 구성 요소보다 더 복잡한 문제에 직면할 수도 있습니다.

우리는 다음 섹션에서 원칙과 주의 사항에 대해 간략히 설명하겠습니다.

이 역시 실제 경험을 바탕으로 한 것이다. 우리는 이미 야생에서 그 모든 패턴을 보았기 때문에 그것은 학문적인 연습이 아닙니다. 이것이 우리가 여러분에게 몇 가지 반패턴을 보여주고 있는 이유입니다. 그래서 여러분은 다른 사람들이 이미 했던 실수로부터 배울 수 있는 기회를 갖게 됩니다.

보안 - 특별 행사

요청 필터링

가장 적합한 필터링 위치

마지막 장 끝에서 알려진 선택기에 대한 들어오는 트래픽을 필터링할 필요성을 지적했습니다. 그러면 질문은 사라집니다. 실제로 어디에서 요청을 필터링해야 합니까?

상황에 따라 다르죠 빠르면 빠를수록 좋습니다.

웹 애플리케이션 방화벽

웹 보안을 위해 설계된 웹 응용 프로그램 방화벽 장치나 "WAF"가 있는 경우 이러한 기능을 반드시 활용해야 합니다. 그러나 WAF는 콘텐츠 애플리케이션에 대한 지식이 제한된 사람만 사용하며 유효한 요청을 필터링하거나 너무 많은 유해 요청을 전달한다는 것을 알 수 있습니다. WAF를 운영하는 직원들이 교대 근무와 릴리스 일정이 다른 부서에 할당되어 있으며, 커뮤니케이션이 직속 팀원들과 같이 긴밀하지 않을 수 있고 항상 시간에 변화를 얻지 못하여 결과적으로 개발 및 콘텐츠 속도가 저하되는 것을 알 수 있습니다.

당신은 몇 가지 일반적인 규칙이나 심지어 당신의 직감이 강화될 수 있다고 말하는 차단 목록에 추가하다로 끝날 수 있습니다.

Dispatcher 및 Publish 필터링

다음 단계는 Apache 코어 및/또는 Dispatcher에서 URL 필터링 규칙을 추가하는 것입니다.

여기서는 URL에만 액세스할 수 있습니다. 패턴 기반 필터로 제한됩니다. 더 많은 컨텐츠 기반 필터링(예: 올바른 타임스탬프가 있는 파일만 허용)을 설정해야 하거나 작성자에서 일부 필터링을 제어하려면 사용자 지정 서블릿 필터와 같은 것을 작성하게 됩니다.

모니터링 및 디버깅

실제로 각 수준에 약간의 보안이 제공됩니다. 하지만 어떤 수준에서 요청이 필터링되는지 확인할 수 있는 수단이 있는지 확인하십시오. Publish 시스템, Dispatcher 및 WAF의 로그 파일에 직접 액세스하여 체인의 어떤 필터가 요청을 차단하는지 확인해야 합니다.

선택기 및 선택기 확산

마지막 장의 "selector-parameters"를 사용하는 접근 방식은 빠르고 쉬우며 새 구성 요소의 개발 시간을 단축할 수 있지만 한계가 있습니다.

"quality" 속성을 설정하는 것은 간단한 예에 불과합니다. 그러나 서블릿은 "폭"에 대한 매개 변수가 더 다용적일 것으로 예상한다고 가정해 보겠습니다.

가능한 선택기 값 수를 줄여 유효한 URL의 수를 줄일 수 있습니다. 너비로도 동일한 작업을 수행할 수 있습니다.

품질 = q-20, q-40, q-60, q-80, q-100

width = w-100, w-200, w-400, w-800, w-1000, w-1200

그러나 이제 모든 조합이 유효한 URL입니다.

이제 하나의 리소스에 대해 5x6=30개의 유효한 URL이 이미 있습니다. 각 추가 속성은 복잡성을 가중시킵니다. 그리고 적당한 값으로 줄일 수 없는 속성이 있을 수 있다.

그래서, 또한 이 접근법은 한계가 있습니다.

균질한 부위 구조의 필요성

statfileslevel은 설정의 모든 사이트에 동일하게 적용됩니다. 따라서 모든 사이트가 동일한 구조를 따르고 동일한 수준에서 시작해야 합니다.

포트폴리오에 일부 브랜드가 있으며 일부 브랜드는 소수의 작은 시장에서만 판매되고 다른 브랜드는 전 세계에서 판매된다고 가정해 보겠습니다. 작은 시장은 하나의 지역 언어만을 가지지만 세계 시장에는 두 개 이상의 언어가 사용되는 국가가 있습니다.

전자는 2 ​의 statfileslevel이(가) 필요하지만 후자는 3 ​이(가) 필요합니다.

이상적인 상황은 아니야 3(으)로 설정하면 하위 분기 /home, /products 및 /about 사이의 작은 사이트 내에서 자동 무효화가 작동하지 않습니다.

이 값을 2(으)로 설정하면 더 큰 사이트에서 /canada/en 및 /canada/fr 종속 항목을 선언하고 있지만 선언하고 있지 않을 수 있습니다. 따라서 /en의 각 무효화도 /fr을(를) 무효화합니다. 이렇게 하면 캐시 적중률이 약간 줄어들지만 오래된 캐시된 콘텐츠를 전달하는 것보다 훨씬 좋습니다.

물론 가장 좋은 솔루션은 모든 사이트의 뿌리를 동일하게 깊게 만드는 것입니다.

사이트 간 연결

어느 수준이 적당할까요? 사이트 간 종속성 수에 따라 다릅니다. 페이지 렌더링에 대해 확인하는 포함은 "엄격한 종속성"으로 간주됩니다. 이 안내서 시작 부분에 티저 구성 요소를 도입했을 때 이러한 포함 ​을 보여 주었습니다.

하이퍼링크 ​는 더 부드러운 형식의 종속성입니다. 한 웹 사이트 내에서 하이퍼링크를 사용할 가능성이 높으며 웹 사이트 간에 링크가 있을 가능성도 낮지 않습니다. 단순 하이퍼링크는 일반적으로 웹 사이트 간에 종속성을 만들지 않습니다. 사이트에서 facebook으로 설정한 외부 링크만 생각해 보십시오. facebook에서 변경되는 내용이 있거나 그 반대로 변경되는 경우 페이지를 렌더링하지 않아도 됩니다.

연결된 리소스(예: 탐색 제목)에서 콘텐츠를 읽을 때 종속성이 발생합니다. 이와 같은 종속성은 로컬로 입력한 탐색 제목에만 의존하고 대상 페이지에서 가져오지 않는 경우(외부 링크에서처럼) 방지할 수 있습니다.

예기치 않은 종속성

그러나 설정에서 - 독립적인 것으로 가정되는 - 사이트가 함께 제공되는 부분이 있을 수 있습니다. 프로젝트 중 하나에서 얻은 실제 시나리오를 살펴보겠습니다.

고객은 마지막 장에 스케치된 것과 같은 사이트 구조를 가지고 있었습니다.

예:

각 나라마다 고유한 영역이 있습니다.

언어 사이트 간에 탐색할 수 있는 링크가 없고 명백한 포함이 없으므로 statfileslevel을 3으로 설정했습니다.

모든 사이트는 기본적으로 동일한 콘텐츠를 제공합니다. 유일한 차이점은 언어였다.

Google과 같은 검색 엔진은 다른 URL에 동일한 콘텐츠가 "기만적"인 것으로 간주합니다. 사용자는 동일한 콘텐츠를 제공하는 팜을 만들어 등급을 더 높게 매기거나 더 자주 나열하려고 할 수 있습니다. 검색 엔진은 이러한 시도를 인식하고 단순히 콘텐츠를 재활용하는 페이지의 등급을 실제로 낮춥니다.

각 페이지의 헤더 섹션에서 각 관련 페이지에 <link rel="alternate"> 태그를 설정하여 투명 순위를 매기고, 실제로는 동일한 콘텐츠를 가진 페이지가 두 개 이상 있으며, 시스템을 "게임"하려고 하지 않을 수 있습니다("Google에 페이지의 현지화된 버전에 대해 알리기" 참조).

모두 연결

일부 SEO 전문가는 이렇게 하면 한 언어로 순위가 높은 웹 사이트의 명성이나 "링크 주스"를 다른 언어로 동일한 웹 사이트로 전달할 수 있다고 주장하기도 합니다.

이 계획은 많은 링크뿐만 아니라 몇 가지 문제를 만들었습니다. n 언어로 p ​에 필요한 링크 수는 p x(n²-n) ​입니다. 각 페이지는 자체(-n)를 제외하고 서로 다른 페이지(n x n)에 연결됩니다. 이 구성표는 각 페이지에 적용됩니다. 4개 언어로 20페이지의 작은 사이트가 있는 경우 각각 240 ​개의 링크입니다.

먼저 편집기에서 이러한 링크를 수동으로 유지 관리하지 않도록 하십시오. 이러한 링크는 시스템에서 자동으로 생성되어야 합니다.

둘째, 정확해야 합니다. 시스템에서 새 "상대"를 감지할 때마다 동일한 콘텐츠(하지만 다른 언어)를 사용하는 다른 모든 페이지에서 연결하려고 합니다.

우리 프로젝트에서는 새로운 상대 페이지가 자주 떴다. 그러나 그들은 "대체" 연결로 구체화되지 않았다. 예를 들어 de-de/produkte 페이지가 독일 웹 사이트에 게시되었을 때 다른 사이트에서는 즉시 표시되지 않았습니다.

그 이유는, 우리의 설정에서 사이트들은 독립적이어야 했다. 따라서 독일 웹 사이트에서의 변경은 프랑스 웹 사이트에서의 무효화를 트리거하지 않았다.

이미 그 문제를 해결하는 방법을 알고 있을 겁니다. statfileslevel을 2로 낮추면 무효화 도메인이 넓어집니다. 물론, 캐시 적중률(특히 발행물 시)도 감소하므로 무효화가 더 자주 발생합니다.

우리의 경우에는 그것은 훨씬 더 복잡했습니다.

같은 내용을 가지고 있음에도 실제 그렇지 않은 브랜드 이름은 각 나라마다 달랐다.

shiny-brand은(는) 프랑스에서 marque-brillant, 독일에서 blitzmarke(으)로 호출되었습니다.

이는 statfiles 수준을 1로 설정함을 의미합니다. 이로 인해 너무 큰 무효화 도메인이 발생할 수 있습니다.

그 부지를 재구조화하면 그것을 고칠 수 있었을 것이다. 모든 브랜드를 하나의 공통 루트 아래에 병합합니다. 하지만 그 당시에는 능력이 없었기 때문에 - 그것은 레벨 2만 주었을 것입니다.

우리는 레벨 3을 고수하기로 결정했고 항상 최신 "대체" 링크를 가지고 있지 않은 가격을 지불했습니다. 이를 완화하기 위해 Dispatcher에서 "리퍼" 크론 작업이 실행되어 1주 이상 지난 파일이 정리되었습니다. 결국 모든 페이지가 어느 시점에 다시 렌더링되었습니다. 그러나 그것은 각각의 프로젝트에서 개별적으로 결정되어야 하는 상충관계입니다.

자동 재가져오기

사이트에 매우 특별한 액세스 패턴이 있습니다. 들어오는 트래픽의 부하가 높고 대부분의 트래픽이 페이지의 작은 부분에 집중됩니다. 홈 페이지, 캠페인 랜딩 페이지 및 주요 제품 세부 사항 페이지에는 트래픽의 90%가 전송됩니다. 또는 새 사이트를 운영하는 경우 최신 문서가 이전 문서에 비해 더 높은 트래픽 수를 갖습니다.

이제 이러한 페이지는 너무 자주 요청되므로 Dispatcher에 캐시될 가능성이 높습니다.

임의 무효화 요청이 Dispatcher으로 전송되어 가장 인기 있는 한 페이지를 포함하여 모든 페이지가 무효화됩니다.

따라서 이러한 페이지가 매우 인기 있으므로 다른 브라우저에서 새로 들어오는 요청이 있습니다. 홈 페이지를 예로 들어 보겠습니다.

현재 캐시가 유효하지 않기 때문에, 동시에 들어오는 모든 홈 페이지 요청은 높은 로드를 생성하는 Publish 시스템으로 전달됩니다.

빈 캐시의 동일한 리소스에 대한 병렬 요청: 요청이 Publish으로 전달됩니다

자동 다시 가져오기를 사용하면 이를 어느 정도 완화할 수 있습니다. 대부분의 무효화된 페이지는 자동 무효화 이후에도 여전히 물리적으로 Dispatcher에 저장됩니다. 고려됨 ​일 뿐입니다. 자동 다시 가져오기 ​는 오래된 콘텐츠를 다시 가져오기 위해 게시 시스템에 대한 단일 요청을 시작하는 동안 이러한 오래된 페이지를 몇 초 동안 계속 제공함을 의미합니다.

백그라운드에서 다시 가져오는 동안 오래된 콘텐츠 제공

다시 가져오기를 활성화하려면 자동 무효화 후에 다시 가져올 리소스를 Dispatcher에 알려 주어야 합니다. 활성화한 모든 페이지는 인기 있는 페이지를 포함하여 다른 모든 페이지를 자동 무효화한다는 것을 기억하십시오.

다시 가져오기는 실제로 각 (!)의 Dispatcher에 알리는 것을 의미합니다. 가장 방문 빈도가 높은 항목과 가장 방문 빈도가 높은 항목을 다시 가져오려는 무효화 요청.

이는 리소스 URL(경로뿐만 아니라 실제 URL) 목록을 무효화 요청 본문에 넣음으로써 수행됩니다.

Dispatcher에 이러한 요청이 표시되면 평소와 같이 자동 무효화가 트리거되고 Publish 시스템에서 새로운 콘텐츠를 다시 가져오기 위한 요청이 즉시 대기됩니다.

이제 요청 본문을 사용하므로 HTTP 표준에 따라 콘텐츠 유형 및 콘텐츠 길이도 설정해야 합니다.

또한 Dispatcher은 내부적으로 해당 URL을 표시하여 자동 무효화로 인해 이러한 리소스를 유효하지 않은 것으로 간주되더라도 이러한 리소스를 직접 전달할 수 있음을 알게 됩니다.

나열된 모든 URL이 하나씩 요청됩니다. 따라서 Publish 시스템에서 너무 높은 로드를 생성하는 것에 대해 걱정할 필요가 없습니다. 그러나 해당 목록에 URL을 너무 많이 넣고 싶지는 않습니다. 결국 너무 오랫동안 오래된 콘텐츠를 제공하지 않도록 제한된 시간 내에 큐를 처리해야 합니다. 가장 자주 액세스하는 10개의 페이지를 포함시키기만 하면 됩니다.

Dispatcher의 캐시 디렉터리를 살펴보면 타임스탬프로 표시된 임시 파일이 표시됩니다. 이러한 파일은 현재 백그라운드에서 로드되고 있습니다.

참조

helpx.adobe.com - AEM에서 캐시된 페이지 무효화

Publish 시스템 보호

Dispatcher은 유지 관리 목적으로만 사용되는 요청에서 Publish 시스템을 차단하여 약간의 추가 보안을 제공합니다. 예를 들어 /crx/de 또는 /system/console URL을 공개하지 않습니다.

시스템에 WAF(Web Application Firewall)가 설치되어 있어도 문제가 없습니다. 그러나 이는 귀하의 예산에 상당한 양을 추가하며 모든 프로젝트가 WAF를 운영 및 유지 관리할 수 있는 여유가 있는 상황은 아닙니다.

자주 표시되는 것은 더 취약한 리소스에 대한 액세스를 방지하는 Dispatcher 구성의 Apache 재작성 규칙 세트입니다.

그러나 다른 접근 방식을 고려할 수도 있습니다.

Dispatcher 구성에 따르면 Dispatcher 모듈은 특정 디렉터리에 바인딩됩니다.

하지만 이후에 필터링해야 할 때 왜 핸들러를 전체 docroot에 바인딩합니까?

우선 처리기의 바인딩 범위를 좁힐 수 있습니다. SetHandler이(가) 핸들러를 디렉터리에 바인딩하면 핸들러를 URL 또는 URL 패턴에 바인딩할 수 있습니다.

이렇게 하는 경우 항상 Dispatcher-handler를 Dispatcher의 무효화 URL에 바인딩해야 합니다. 이렇게 하지 않으면 AEM에서 Dispatcher으로 무효화 요청을 보낼 수 없습니다.

Dispatcher을 필터로 사용하는 또 다른 방법은 dispatcher.any에서 필터 지시문을 설정하는 것입니다.

우리는 한 지시어의 사용을 다른 지시어의 사용을 의무화하고 있는 것이 아니라 모든 지시어의 적절한 혼합을 권장하고 있다.

그러나 필요한 만큼 가능한 한 빨리 체인 내에 URL 공간을 좁히고 가능한 가장 간단한 방법으로 좁히는 것을 고려해 볼 것을 제안합니다. 이러한 기술은 매우 민감한 웹 사이트에서 WAF를 대체하는 것이 아니라는 점을 여전히 명심하십시오. 어떤 사람들은 이런 기술을 "가난한 사람의 방화벽" 이라고 부르는데, 그 이유가 있다.

참조

apache.org- sethandler 지시문

helpx.adobe.com - 콘텐츠 필터에 대한 액세스 구성