'ASP.NET'에 해당되는 글 4건

  1. 2008.09.11 L4스위치나 NLB로 웹서버 웹팜 구성시 특정 웹서버 오류...
  2. 2008.09.11 ASP.NET 페이지 요구시 처리 과정
  3. 2008.08.28 ASP.NET 2개 폼 사용하는 꽁수
  4. 2008.07.30 UTF-8로 웹 사이트 배포하기
2008.09.11 08:59

L4스위치나 NLB로 웹서버 웹팜 구성시 특정 웹서버 오류...

몇몇 사이트에서 간혹 발생하는 문제로 각각 웹서버 로컬상에서 웹페이지가 이상없이 동작하나 L4장비에 서버를 붙이면 viewstate값의 오류가 발생하는 문제가 발생할 수 있으며, 이는 아래 노란색 부분의 machineKey값이 없어서 발생할 수 있습니다.

<!-- machineKey
            validationKey="AutoGenerate,IsolateApps"
            decryptionKey="AutoGenerate,IsolateApps"
            validation="SHA1" / -->
             <machineKey validationKey="8A3EBB645F310967C2C3DC76C7B6D5336313B1A3C20E3456CADA1566F25E8A8540642E50396A69FB04CA05AB3CB6BCDD83705BF6224623D32E4E20B31073ED38"
decryptionKey="5FA3EE464868418BEB56B183ECB156347DC13EB91163F0F6"

validation="SHA1"/>

l  Machine.config validationKey 설정

   WebFarm 구조에서는 viewstate corrupt 되었다는 오류 페이지가 간혹 발생할 수 있습니다. 이것은 해쉬 방식의 L4를 사용하지 않아 사용자가 웹서버 사이를 이동할 수 있는 형태의 WebFarm에서 발생하는데, 닷넷 페이지의 특성인 포스트백이 일어날 때 원본 viewstate을 다른 서버에서 해독하지 못하는 경우에 발생합니다.. 이 문제는 MS 디자인 버그이며 이를 해결하기 위해서는 모든 웹서버의 validationKey를 동일하게 설정해야 합니다. 이러한 validationKey를 얻기 위해 home밑의 GetValidationKey.aspx를 호출하거나 etc폴더 밑의 GetValidationKey.exe를 실행하여 결과물을 Machine.config의 다음 부분에 대체하면 됩니다.

 <machineKey validationKey="AutoGenerate,IsolateApps"
  decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/> 


참고글: http://blog.naver.com/saltynut?Redirect=Log&logNo=120019245399

L4
NLB를 사용하여 여러 대의 웹 서버를 묶어서 동작시키는 웹 팜(Web Farm) 환경에서 ASP.NET을 사용하는 경우, 상태 관리 문제가 이슈가 됩니다. 대표적인 것이 ViewState Session, 폼 인증 쿠키 등이 있겠습니다.

예를 들어 ViewState와 관련하여 PostBack 시에 다음과 같은 에러 메시지가 발생할 수 있습니다.

HttpException (0x80004005): The View State is invalid for this page and might be corrupted.]
   System.Web.UI.Page.LoadPageStateFromPersistenceMedium() +150
   System.Web.UI.Page.LoadPageViewState() +16
   System.Web.UI.Page.ProcessRequestMain() +421
.

 아마 한글 메시지로는 '이 페이지의 뷰 상태가 유효하지 않거나 훼손되었습니다.'라는 걸로 나오던 걸로 기억합니다.

 
이 문제가 발생하는 원인을 살펴보겠습니다.

웹 팜 환경에서는 최초 페이지 접근은 A 서버로 하고, PostBack B 서버로 날라갈 수도 있습니다.


PostBack
동안 ViewState가 페이지에서 저장/로드될 때는 특정한 키를 사용하여 Encrypt/Decrypt 되는 과정을 거치게 됩니다. 그런데, 이때 사용하는 키 값이 A 서버와 B 서버가 서로 다르게 설정되어 있을 것이기 때문에 위와 같은 에러가 발생하게 됩니다.

폼 인증 사용 시 쿠키와 관련한 문제도 이것과 동일합니다.


 
이 문제를 해결할 수 있는 방법은 크게 2가지입니다.

우선 첫번째는 L4 장비에서 세션이 유지되도록(, 한 사용자는 최초 접근한 서버로 계속 접근하도록) 설정하는 방법이 있습니다. 이 방법을 사용하면 상태 관리 문제(세션변수, ViewState, 폼인증 쿠키)를 모두 잊어버려도 된다는 장점이 있는 대신에, 로드 밸런싱의 효율성이 떨어지게 됩니다.

그래서 권장되는 두번째 방법은 바로 모든 웹 서버의 키 값을 동일하게 설정해주는 것입니다. 키를 생성하고, machine.config를 수정하는 부분에 대해서는 다음 KB를 참고하십시오.


 
http://support.microsoft.com/default.aspx?scid=312906

 
그러나, 세션변수(Session)의 경우에는 두번째 방법으로 해결되지 않습니다. 세션 변수는 페이지에 저장되는 것이 아니라 웹 서버의 메모리에 저장되는 것이기 때문입니다. L4 설정을 하지 않고 세션 변수를 공유하는 방법은 없을까요? 바로 ASP.NET StateServer SqlServer 모드 등을 통해 세션을 별도로 관리하는 방법이 있습니다. 여기에 관해서는 다음 URL을 참조하십시오.

 
http://msdn.microsoft.com/library/KOR/cpguide/html/cpconSessionState.asp

 
웹 팜에서 StateServer SqlServer 모드를 사용할 때는 주의해야 할 사항이 하나 있습니다. 다음 URL을 반드시 참고하시기 바랍니다.

 
http://support.microsoft.com/default.aspx?scid=325056

 
마지막으로 Session 변수와 ViewState에 대해 참고할 만한 좋은 문서가 있습니다. ASP.NET Program Manager Susan Warren이 작성한 다음 문서를 보기 바랍니다.

 
http://msdn.microsoft.com/library/en-us/dnaspnet/html/asp11222001.asp


출처 : http://pinkwine79.tistory.com/187
신고
Trackback 14 Comment 0
2008.09.11 08:57

ASP.NET 페이지 요구시 처리 과정

ASP.NET 페이지 요구시 처리 과정
 - *.aspx
 - 클라이언트가 특정 페이지를 요구할 때마다 메모리 상에 페이지 객체는 생성, 소멸까지 일련의 과정을 거친다.

1. Init
 - 페이지 객체가 생성된 후 초기화 단계
 - 뷰스테이트 값 복구 전 단계, 저확한 컨트롤 참조 불확실
 - 이벤트 핸들러 매칭이나, 컨트롤 동적 로딩에 적합

2. ViewState복구
 - 뷰스테이트 복구 단계
 - 페이지 처음 요청시 건너뜀

2.5 다시 게시된 데이터 처리
 - 들어오는 폼 데이터를 처리하고, 그에 알맞게 속성을 업데이트합니다.
 - 다시 게시된 데이터를 처리하는 컨트롤만 이 단계를 수행합니다.

3. Load **
 - 뷰스테이트 값이 복구가 완료된 단계
 - 서버 큰트롤에 접근 가능(정확한 값을 가지고 있는 상태)
 - 모든 컨트롤이 탑재되고 값이 복구된 상태
 - 가장 많이 코딩하는 장소

4. PostBack 이벤트 처리 **
 - 사용자가 발행한 이벤트 처리 단계
 - 페이지가 처음 요청될 때는 이 단계는 건너뜀(IsPostBack이 false일때)

5. PreRender
 - 컨트롤을 랜더링하기 바로 전 단계
 - 처리 순서로 인해 발생하는 논리 문제를 해결하기 위해 Load해서 해야할 처리를 여기서 대신 가능

5.5 ViewState 저장
 - 컨트롤의 상태를 저장, 클라이언트에게 되돌려줌

6. Render
 - 컨트롤을 출력할 HTML로 랜더링 하는 단계

7. UnLoad
 - 페이지 객체가 소멸되기 전에 발생하는 단계
 - 페이지 요청시 항상 실행된다.(try-catch에서 finally처럼)
 - 클린업 코드 처리(리소스 반환)
 - 뷰스테이트 처리는  여기서 안함(아무 소용 X)


출처 : http://no1power.tistory.com/42

신고
Trackback 8 Comment 0
2008.08.28 08:49

ASP.NET 2개 폼 사용하는 꽁수

태요님에 강좌중에 찾은 Form 2개 사용...

http://taeyo.pe.kr/Columns/View.aspx?SEQ=81&PSEQ=8&IDX=0
신고
Trackback 0 Comment 0
2008.07.30 11:22

UTF-8로 웹 사이트 배포하기

UTF-8로 웹 사이트 배포하기

 

1. 개요


VS.NET
에서 웹 사이트를 배포할 때 Web.config 파일의 전역화 설정을 보면

 

<globalization requestEncoding="ks_c_5601-1987" responseEncoding="ks_c_5601-1987"/>

 

로 설정되어 있습니다.


Ks_c_5601-1987
은 캐릭터 셋의 명칭이고 이것의 인코딩 명칭은 EUC-KR 입니다.


즉 위에 euc-kr 로 써야 할 명칭이 Ks_c_5601-1987 로 잘못 쓰여졌다는 논란이 있기도 합니다만,


결국은 웹 사이트를 euc-kr로 배포하겠다는 의미를 나타냅니다.


하지만 외국 사이트에서 euc-kr로 인코딩된 웹 사이트로 접근시 글자가 깨지게 됩니다.


그렇기 때문에 외국에서 한글 사이트를 배포해야 할 경우가 발생할 때 표준 인코딩 방식인 UTF-8로 인코딩 해야 합니다.


그럼 asp.net 사이트에서 utf-8로 인코딩하기 위해서 어떻게 해야 하는지를 알아보도록 하겠습니다.


 

2. aspx 파일

 

웹 사이트의 aspx 파일은 aspnet_isapi.dll을 통해 전역적인 설정이 web.config에 영향을 받게 됩니다.


결국 web.config의 전역화 설정을 지정함으로서 aspnet_isapi 필터로 들어오는 확장자들은 모두 utf-8로 인코딩이 됩니다.


설정은 아래와 같이 해주시면 됩니다.

 

<globalization requestEncoding="utf-8" responseEncoding="utf-8"/>

 


3. css / js / html / etc
파일

 

Css / js / html / etc 파일들은 web.config의 설정으로 반영되지 않습니다.


Euc-kr
로 인코딩된 이들 파일들의 내용 중 한글이 있다면 글자가 깨집니다.


이들 파일들은 메모장으로 열어 다른 이름으로 저장한 다음 인코딩 방식을 UTF-8로 지정해 줍니다.

 





















 


저장한 후 덮어쓰시면 이 파일 자체를 UTF-8로 인코딩하므로 웹 사이트에서 페이지를 볼 때 한글이 제대로 나오게 됩니다.

 


4.
언어팩


예전에 다국어 관련 비슷한 작업을 할 때 windows 98 OS에서 테스트를 했었으나 다 깨지는 문제가 발생했었습니다.


당시 그 OS에는 언어팩이 설치가 되질 않아 캐릭터 셋이 존재하지 않기 때문에 글자가 깨지는 원인이었습니다.


Windows XP
에는 왠만한 대부분의 국가들의 언어팩이 설치되어 있기 때문에 UTF-8로 인코딩 시 깨지는 경우는 거의 없을 것입니다.
, 한글 언어팩이 설치가 안되있는 OS라면 깨지겠죠..

 



글로벌 서비스를 할 때 js, css, html 파일들에 한글을 넣는 것에 대해 부담을 가지시는 분들이 계시는 것 같아

조금이라도 도움이 될까 작성해 봤습니다.


출처 : http://tit99hds.egloos.com/1907207

신고
Trackback 1 Comment 0


티스토리 툴바