http://www.apacheweek.com/features/reverseproxies

 

 

음.. 어려운게 아니라서, 여기 요약번역한걸 한번 읽어보시던지, 아님 바로 위사이트를 참조하셔도 될 거 같습니다.

편하신데로  참조하삼~

 

 

 

아래 주어담기(1)만이 다가 아니지욤~!!

application server가 그 자신에게 reference를 생성한다면, 밖의 internet에 바로 그 url을 넘기면 동작하지 않게 됩니다.

 

예로, URL의 끝 "/" (trailing slash) 를 붙이지않아서  HTTP redirection 이 종종  발생하는데요.

즉 http://www.example.com/app1/foo 를 요청하면 http://internal.example.com/foo로 변환되서, 요게 뒤에 "/"를 붙여 아래와 같은 식으로 redirection response를 생성하겠지요..

 

HTTP/1.1 302 Found
Location: http://internal.example.com/foo/
(etc)


그러나 internet에서는 실제 위 호스트를 모르기 때문에 "No such host" error가 생깁니다. proxy가 Location header를 원래 address space로 re-map해서 알맞은 URL을 return할 필요가 있다.

ProxyPassReverse 라는 command가 HTTP Header에 이런 re-map을 가능하게 한다.

 

Apache 문서가 제안하는 형식은:
ProxyPassReverse /app1/ http://internal1.example.com/
ProxyPassReverse /app2/ http://internal2.example.com/

 

 

writer가 추천하는 다소 robust한 대체형식은:

<Location /app1/>
  ProxyPassReverse /
</Location>
<Location /app2/>
  ProxyPassReverse /
</Location>


위 방식을 추천하는 이유는 몇몇 application server가 일으키는 문제때문입니다.

 

한 예로, redirect를 해야한다고 가정해보죠:

 

  HTTP/1.1 302 Found
  Location: /some/path/to/file.html


 

실제 위 형식은 HTTP protocol 위반이고 발생되지 말아야합니다: HTTP는 Location Header에 full URL만을 사용가능함. 그러나, 실제로는 CGI spec에서는 relative path도 허용가능한 비슷한 location header도 적혀있고, 실제 외부에는 수많은 broken server들이 있으므로, 위 첫 형식으로의 ProxyPassReverse서버는 incorrect response를 반환하지만, 두번째 형식은 이것을 다음과 같이 변환가능합니다.

 

  HTTP/1.1 302 Found
  Location: /app2/some/path/to/file.html


여전히 broken url이지만, 적어도 error-correcting browser에서는 작동하고, 실제 대부분의 browser는 error-correcting을 지원합니다.

 

backend server가 쿠키를 사용한다면, ProxyPassReverseCookiePath 와 ProxyPassReverseCookieDomain 이 필요합니다. 이것들은 ProxyPassReverse와 비슷하지만, cookie header의 다른 형식들도 처리합니다.

 

Fixing HTML Links
위에서 보듯 ProxyPassReverse 는 회사 네트워크 밖에서 작동가능하게 HTTP header안의 URL을 remap합니만, 실제 HTML 페이지에서 나타나는 링크상에서는 여러가지 문제가 있을 수 있습니다.
아래 경우를 보지요:


<a href="somefile.html">This link will be resolved by the browser and will work correctly.</a>
<a href="/otherfile.html">This link will be resolved by the browser to http://www.example.com/otherfile.html, which is incorrect.</a>
<a href="http://internal1.example.com/">This link will resolve to "no such host" for the browser.</a>
위와 같은 문제는 이미지나  stylesheet, applet script같은 included content에서도 마찬가지로 발생하지요.

 

이런 문제를 수정하기위해서는 HTML을 parsing하고 link를 rewrite해야합니다. 이러기위해 사용하는 모듈이 mod_proxy_html 이지요. mod_proxy_html을 셋업하기 위해서는 아래 configuration directives가 필요합니다.

 

SetOutputFilter proxy-html This simply inserts the filter, to enable ProxyHTMLURLMap
ProxyHTMLURLMap from-pattern to-pattern [flags] In its basic form, this has a similar purpose and semantics to ProxyPassReverse. Additionally, an extended form is available to enable search-and-replace rewriting of URLs within Scripts and Stylesheets.
 

 

How it works

 

mod_proxy_html은 SAX parser이 근본을 둡니다.  HTML 4 와 XHTML1 에서 발생할 수 있는 모든 URI attributes의 모든 개볌을 가지고 있고요. URL을 만날때마다 ProxyHTNLURLMap 방침에 따라 매치되어서 어떤 from-pattern으로 시작된다면 to-pattern으로 rewrite되지요. 해당 rule은 httpd.conf에 나타난것의 reverse order로 적용되고, 매칭을 발견하면 매칭로직은 멈추게 됩니다.

 

 

HTML reverse proxy를 셋업하는 방법은 이렇습니다. 우선  internal server로의 full link는 어디서 발생하든지간에 rewirte되어야합니다. 그래서:

ProxyHTMLURLMap http://internal1.example.com /app1
ProxyHTMLURLMap http://internal2.example.com /app2


여기서 "traling" slah는 생략했다는 점을 주목하십시요.  matching logic의 첫단계이고 minimal matching pattern을 사용해서  우선 위3가지 경우중 3번째 케이스를 수정했습니다.

 

두번째 케이스는 조금 더 신경써야합니다. link가 호스트명을 포함하지 않아서 rewrite rule이 context-sensitive해야하기 때문이지요. 이 경우는 위 ProxyPassReverse와 같이 "<Location>" 을 사용해서 처리합니다.

 

<Location /app1/>
  ProxyHTMLURLMap / /app1/
</Location>
<Location /app2/>
  ProxyHTMLURLMap / /app2/
</Location>


이제 마지막으로 하나만 더 처리합시다.

위에서 "/"패턴을 "/app1/" "/app2" 패턴으로 매칭했기때문에 URL rewriting이 recursive하게 뺑뺑이 돌 수 있습니다.  따라서 아래 rule을 더해줍니다:

 

<Location /app1/>
  ProxyHTMLURLMap / /app1/
  ProxyHTMLURLMap /app1 /app1
</Location>
<Location /app2/>
  ProxyHTMLURLMap / /app2/
  ProxyHTMLURLMap /app2 /app2
</Location>


 

oK? 이해됐으리라봄다..^^;

 

여기서 이것들은 오직 HTML Link에서만 동작한다는 것을 주의해주십시요. 만약 extended URL mapping을 사용한다면, 두번째 rule은 event나 script, sytlesheets에서는 효과가 발생하지 않게 됩니다.

 

 

Extended URL Mapping

 

위에서 HTML URL remapping 셋업을 해봤는데요. 말씀드렸듯이 stylesheet이나 Script에서의 URL은 여전히 remap되지 않고 있겠지요. 이렇게 mod_proxy_html이 js나 css를 파싱하지 않기때문에 그 안에 있는 URL들은 text-based search-and-repace 가 필요합니다. 이것은 ProxyHTMLExtended On 을 셋팅함으로서 가능해집니다.