HTML/XHTML 버전별 DTD 선언 방법

HTML 2.0 표준 문서 형식
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">

HTML 3.2 표준 문서 형식
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

HTML 4.01 표준 문서 형식[Strict, Transitional, Frameset 순]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">

XHTML 1.0 표준 문서 형식[Strict, Transitional, Frameset 순]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

XHTML 1.1 표준 문서 형식[XHTML 1.1은 무조건 Strict 입니다.]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

XHTML 모바일 1.0 문서 형식
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/DTD/xhtml-mobile10.dtd">




Strict: HTML/XHTML 표준을 정확히 준수.
Transitional: Strict 하게 작성할 수 없을 때.
Frameset: frame을 사용하는 것을 명시. (XHTML 1.1부터 frame 사용이 금지됨)

크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by 장현준

2008/05/21 12:33 2008/05/21 12:33
, ,
Response
No Trackback , No Comment
RSS :
http://b4you.net/blog/rss/response/169

blankus 님의 블로그에서 트랙백 합니다. ===============================

아래 글에서도 밝혔듯이, HTML에서 페이지를 로딩할 때 생성되는 HTTP Connect을 알아보았다.
분석을 하기 전 최대한 논쟁을 정리하기 위해 용어 정리 및 몇가지 사항을 나열해보도록 하겠다.

* HTTP Connection: "TCP connection 중 client에서 web server로 연결되는" connection을 의미한다. 정확히는 web browser에서 web server의 daemon 또는 service가 제공하는 port로 연결할 때 발생하는 connection을 의미한다. (보통 web server가 제공하는 port는 80번 포트이므로, client가 80번 포트로 연결한다면 HTTP connection이 발생한다고 볼 수 있다. 포트 번호를 변경한다면 물론 80번 이외의 포트로 연결하더라도 HTTP connection을 의미한다.)
이는 HTTP라는 Protocol자체의 connection를 나타내며, HTTP이라는 Protocol이 TCP라는 Protocol을 이용하기 때문에 "TCP를 이용한 프로토콜 중 하나"라고 할 수 있으며 따라서 위와 같은 설명이 가능하다.

* wininet: wininet.dll 라이브러리 형태로 제공된다. Gopher, FTP, HTTP와 같은 protocol들을 좀 더 편하게 이용할 수 있도록 Windows에서 제공하는 API를 의미한다.

The Windows Internet (WinINet) application programming interface (API) enables applications to interact with Gopher, FTP, and HTTP protocols to access Internet resources.
(출처: http://msdn2.microsoft.com/en-us/library/aa383630.aspx)


* winsock: winsock.dll 또는 wsock32.dll, ws2_32.dll로 제공된다. Windows상에서 socket을 server 혹은 client를 제작할 때 사용하기 위한 library로, 보통 TCP의 전송 계층부터 응용 계층까지 작성할 때 이용할 수 있다.

Winsock provides a Service Provider Interface for creating Winsock services, commonly referred to as the Winsock SPI. Two types of service providers exist: transport providers and namespace providers.
(출처: http://msdn2.microsoft.com/en-us/library/ms737522.aspx)


용어 정리가 끝났으니 다시 HTTP Connection에 대해 살펴보도록 하자.
살피기 전에 blankus님께서 질문해주신 부분을 답변하도록 하겠다.

===============================================================================
blankus님의 Q:
제 테스트는 IE-iwatch / FF-firebug를 통하여 덤프를 떴으며, IE가 wininet을 이용하지 않는다는 것은 처음듣는군요. wininet의 서버당 연결제한수는 HTTP 스펙을 따르는것인데 말이죠. 그리고 http connection고 tcp connection을 헛깔리시는게 아닌가 합니다.
A:
제가 "최소한 IE에서는 저 API를 사용하지 않는것으로 보이며, 80번 포트로 바로 접속해서 결과를 얻어오고 파싱한다고 유추해 낼 수 있습니다."
라고 말한것과 같이, 이것은 제 추측이며 실제로 internet explorer의 dependency를 체크하면 wininet은 분명히 사용하고 있고, winsock은 사용하지 않고 있습니다.
이렇게 보면 제가 말한게 당연히 틀리게 됩니다. 이부분은 인정합니다. 그럼에도 불구하고 제가 wininet을 사용하지 않는다고 생각한 이유는 저 document에서 wininet은 같은 host에 connection의 개수가 여러개 맺어짐을 tcpview를 이용하여 확인하였기 때문입니다.
실제로 wininet을 이용했는데 저렇게 connection이 발생할 수 있다면 자신들이 작성한 문서의 내용을 지키지 않았다고 생각할 수 밖에 없습니다. 그래서 제가 저런 말을 한것입니다. 실제로 어떤 룰에 의해 저렇게 결과가 나오는지는 소스를 보거나 disassembly 해보기 전까지는 모르는 일이죠. wininet에 있는 export되지 않은 다른 API를 사용했을 수도 있구요. M$에서 이런일이 워낙 많기 때문에(apache가 IIS를 따라가지 못하는 이유같이 M$에서는 자체적으로 documentation 되지 않은 내용을 많이 사용하는 사례가 있어서요.) 그렇게 생각을 하고 저렇게 결론을 지은것이죠.
분명히 우리 눈에 TCP connection이 여러개 맺어진 게 볼 수 있는데.. 문서상에서는 아니라고 하니 말입니다.
"wininet을 사용하기는 하지만 사용하지 않는?" 기괴한 상황이라고 볼 수 있습니다.

그리고, TCP connection이 서버의 80번 포트에 발생한다면, 그것은 HTTP connection이라고 할 수 있는걸로 알고 있습니다만. 이 부분에 대해 제가 잘못 알고 있는것인지 궁금합니다. HTTP 자체가 TCP에 근간을 하고 있는 protocol이거든요. 따라서, HTTP connection은 TCP connection중 HTTP port를 이용할 때의 connection 이라 볼 수 있습니다.(보통 80번 포트이죠.)
서버에 방화벽을 개발 할 때, HTTP 방화벽은 80번 포트로 지나다니는 패킷을 파악합니다. 이것은 HTTP라는 것 자체가 TCP에 속하기 때문에 가능하며, TCP 패킷을 필터링 한다면 자연스럽게 HTTP도 필터링이 가능한 것이구요.
그래서 제가 생각하는 HTTP와 TCP connection의 관계는 HTTP < TCP 라고 생각하는 바입니다.
===============================================================================

답변은 여기까지로 하고, 나머지 부분을 보자. 오늘의 글은 dependency를 기준으로 설명할 예제이다.
이쪽 부분은 요즘에 수행하는 프로젝트와 관련이 있는 부분이라서, 나한테도 도움이 될 것 같아서 쓰잘데기 없어보여도;; 정리를 해 놓았다.

아래 그림은 FF에서 과연 wininet을 사용할까? 라는 의문에서 조사를 한 결과이다. "DI"아이콘은 PE Explorer에서 delay import를 나타낸다고 하는데, 정확하지는 않지만 아마도 import section에는 명시되어 있지 않지만 import를 할 가능성이 있는 모듈을 의미하는 것 같다.
아래의 dependency는 실제 사용하지 않는 dll까지 나타나며, 그 이유는 만약 FF가 shell32.dll을 사용한다면 그 안에 있는 dll 까지 표시되기 때문이다. 따라서 실제로 사용될지는 import section을 살펴보아야 한다.


위의 그림에서 확인하였듯이, 우선 FF는 winsock, wininet을 사용 할 가능성을 보이고 있다. 그러면 import section을 보도록 하자.


import section의 shell32.dll에서, wininet에 관련된 함수는 전혀 call 하지 않는 모습을 볼 수 있다. 결론은 winsock만을 이용한다는 것. winsock을 이용하는 부분은 nspr4.dll을 따라가보면 알 수 있다.


왜 좋은 socket 표준 함수를 놔두고 winsock32의 함수들이 왜 저렇게 표시되는지는 알 수 없다; 아마도 WSA~ 류의 함수들이 def파일에 의해 'mangled' 당한게(?)아닐까 생각한다. (필자는 wsock32.dll보단 ws2_32.dll을 이용하기 때문이다) 이게 아니라면, 묵시적 연결을 통해 socket을 사용할 수도 있다. (하지만 보통 socket programming에서는 이렇게 사용하지 않는다)

FF에서 wininet을 이용하지 않는것을 파악했으니 이제 IE를 살펴보도록 하자.

IE에서 wininet을 참조한다. 얘도 바로 import 하지 않고 shell32.dll을 거친다. 물론 import section을 확인해봐야겠지.


확인 결과 SHELL32.147을 호출한다. 이게 무엇일까? 알수 없다. 아마도 내 생각엔, 이걸 보기보다는 저 아래에 있는 ieframe.dll을 보아야 하지 않을까 생각하는데.. 추적 끝에 직접적으로 wininet을 호출하는 부분을 찾을 수 없었다. 그러면 어디로 숨은걸까? 그건 IE 개발자한테에게로 -_-..
(아마도 이 부분에서 HttpRequest~~에 대한 논란이 발생되었을 수도 있다. 하지만 직접적으로 import 하는 부분에는 HttpRequest~ 가 없는걸 확인할 수 있다. (mangle될 수도 있다. 이건 M$ 마음이기 때문에 내가 알아낼 수 있는 길이 없다)


원래대로라면.. 아래에서 볼 수 있듯이.. 얘네를 호출해야되는데 말이다. 알수없는 M$.




실제로 앞에서 언급하였듯이 소스 코드를 보거나, disassembly하기 전까지는 정확히 어떤 API를 사용하는지 알 수 없다. M$의 document에서 자신들은 wininet에 호스트 접속 수를 제한하였다고 하였는데..
IE가 만약에 document에 나온대로 wininet을 이용하고 HttpRequest~ API를 이용하는것과 같이 충실히 따라주었다면 절대 아래 포스팅 한 글같이는 나오지 않을 것이다.
이 부분에 있어서 필자는 내부적으로 socket을 이용하지 않을까 라는 추측을 해 보았으며, 이 socket을 이용한 API가 wininet에 undocumented 상태로 있을지도 모르는 일이다. (진실은 저넘어에)

마지막으로 FF에서 아래 포스팅 한 글대로 테스트를 하였을 때 결과다. 스샷은.. 힘들어서 되도록이면 생략하도록 하겠다.
이 테스트를 위해.. 오늘 FF를 설치하였다 :)
(필자는 업종이 웹쪽이 아니다보니.. 평소에 FF를 사용하지 않는다;; )

* 크기가 24,159,200 Byte인 HTML 문서에 접속 할 경우 (1개의 connection)
IE와 동일하다. 1개의 HTTP connection이 발생한다.

* 크기가 4,840,000 인 js 파일을 15개 포함하는 HTML 문서에 접속 할 경우
IE와 동일하다. 한번에 1개의 JS 파일을 다운로드 한다. 여러개를 동시에 받은 뒤 나중에 파싱을 하는게 어떨까.. 라고도 생각을 해본다.^^;

-- 나중에 페이지를 옮기려니 오류가 나면서 종료된다^^;; FF의 버그인듯.
-- 재시작 하니 FF 세션 복구 기능이 있군! 역시 좋다;;

* 크기가 1,550,742 인 gif 파일을 19개 포함하는 HTML 문서에 접속 할 경우
"IE와는 다르게 그림 파일을 2개씩 받아온다." 이 부분에서 blankus 님과 다른 의견을 보인게 아닐까 한다. 하지만 FF에서는 wininet을 사용하지 않을 확률이 매우 높기 때문에 내부적인 정책으로 생각해 볼 수 있다. 하지만 어떠한 경우에도 레지스트리의 MaxConnectionsPerServer 값과는 상관이 없는 듯 하다. 필자는 원래부터 MaxConnectionsPerServer 값을 10(0xa)으로 해놓고 사용중이기 때문이다.
(솔직히 이부분은 FF의 소스를 분석해보기 전까지는 모르는 일이다.)
개인적인 생각으로는, 2개정도씩 불러오면 되겠지 라고 생각을 해서 이렇게 한 것 같다.
(멀티플렉싱 기법을 이용하지 않는 스레드 2개를 파일 다운로드에 쓰면 이렇게 될 수 있다. 멀티플렉싱 쓰면 IE와 같이 스레드 2개에서 파일을 여러개 다운로드 할 수 있다)




결론은, (휴 힘들다^^;;) IE에서 HTTP Connection의 제약은 없다고 판단되며, FF에서는 wininet을 통한 제약이 아닌, 자체적인 정책에 의해 그림파일과 같은 파일의 다운로드 개수를 제한하는것을 볼 수 있다. 이것은 MaxConnectionsPerServer값을 수정해 본 결과 M$문서에 언급되어 있는 내용과 다르다고 생각할 수 있다.

성능상의 문제로 제약해놓고... 자기네들은 지키지 않는 M$를.. 뭐라고 해야될까.


===================== 나중에 발견한 blankus님의 질문에 대한 답변입니다^^;; (위에선 이부분을 못봤네요)
1. 브라우저는 인터넷에서 리소스를 다운받을때 activex가 아닌이상 기본적으로 http 프로토콜을 통하여 처리가 됩니다. 말인즉, http connection이 발생하고 그 파이프라인을 통해 정보가 다운되는 것입니다. 그리고 tcpview를 근거로 제시하셨는데, 저또한 그프로그램으로 정보를 추출해본결과 아래와 같습니다.

=> 물론 HTTP를 이용합니다(첨언하자면 HTTP에서 P가 protocol이기 때문에 HTTP프로토콜이란 말은 엄밀히 따지면 아닙니다^^). 위에서 설명한것과 같습니다. wininet과는 상관이 없는 것 같네요. 제가 FF를 사용하지 않다 보니, IE만으로 테스트를 하였었습니다. FF를 고려하지 못한 이 부분은 사과드리겠습니다^^

2. 작은이미지라서 커넥션이 빨리끊기고하여 2개씩 보일 수 있다구요? 참으로 어리석은 생각입니다.

=> 1번과 동일합니다. 실제 IE에서 테스트 했을 당시 이미지들의 로딩이 불규칙적으로 되는것을 확인할 수 있었습니다. ms까지 나오는 툴이 없어서 스샷은 첨부하지 못했습니다.

3. html+이미지 갯수 = http connection갯수 라는 논리의 근거를 제시해달라고 했더니 트랙백 글에선 말을 바꾸시던데 왜 그랬나요? 실제로 테스트해보니 생각과는 달랐나요? http 1.1의 규약처럼 reg값을 기본으로 변경(2개)하여 테스트해보세요. 그래도 이런 생각을 하게될까요?


=> 1번과 동일합니다. 추가하자면, 말바꾼적은 없구요~ http connection의 최대 갯수 라고 해야 정확할 것 같습니다. 글 쓰다보니 "최대" 자를 빼먹은점 사과드립니다. HTTP 1.1의 규약을 제가 잘 모르기도 하지만요^^

4. IE가 wininet을 이용하지 않는다는 근거는 어떤것인가요? 이부분은 참으로 이해가 안가는 부분이군요. 자료를 첨부해주세요.

=> 위에서 그림을 첨부하여 설명드렸습니다.

5.FF가 다른 커넥션구조를 갖는다고 어디에 누가그러던가요? 자료를 첨부해주세요

=> 소스 분석까지는 곤란하겠습니다. 위의 import section을 통해 매우 높은 확률로 wininet을 사용하지 않는다는것을 보실 수 있습니다. 일반 socket을 사용할 확률이 높죠

6. 4번과 같은 맥락인데, http connection의 갯수와 관련 IE가 W3C의 HTTP 1.1의 기준에 미달한다는 자료를 첨부해주세요.

=> 음.. 이 질문에 대해서는 답변해드리기가 힘듭니다. 제 지식이 짧아서요^^; 솔직히 HTTP 1.1에서 connection의 개수가 2개로 정해졌다는 내용이 있는지도 잘 모릅니다.^^; 저는 보여지는 내용을 토대로 작성하였으며, 이 질문에 대해서는 문서를 찾아봐야되는데.. 관련 지식이 매우 부족해서 답변해드릴수가 없습니다~
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by 장현준

2007/07/23 11:46 2007/07/23 11:46
,
Response
No Trackback , a comment
RSS :
http://b4you.net/blog/rss/response/125

blankus 님의 블로그에서 트랙백 합니다.
===============================

우리가 실제로 웹 페이지에 접속할 때 생성되는 connection의 개수는 얼마나 될까?
일반 사용자들이야 궁금해 할일이 없겠지만, 서버단에서 성능을 위해 connection의 개수를 확인해 볼 필요가 있을지도 모른다.

이번 글은 오전에 blankus 님의 블로그(blankus.net)에서 connection에 대한 글을 보았고, 리플을 달았었는데 그에 따른 답변이 있어서 포스팅 하게 되었다~

blankus 님은, FF를 사용하기 때문에 내가 작성한 결과와는 조금 다를 수 있다.(browser에서 thread를 몇개 돌리냐, 한번에 파일 다운로드를 몇개 하느냐에 따라 모두 달라지기 때문이다. 하지만 요즘 browser들은 성능상을 좋게 하기 위해 한번에 여러개의 파일을 처리하며, 이 가정 하에 결론을 내리도록 하겠다)

우선 오늘 "동시접속" 확인을 위해 사용된 응용 프로그램에 대해 알아보자.
이름은 TCPView라고 하며.. SysInternal(현재 MS에 인수되었다)사에서 제작한 응용 프로그램이다.
성능은? 안정성은?
일반 업체에서 이 응용 프로그램을 이용하여 웜 및 바이러스를 진단하기도 한다. (대형 업체에서는 자체 툴을 만들어 쓰므로 패스~)
나 또한 전에 다니던 회사에서 anti-spyware 프로젝트를 할 때 이 툴을 이용하여 분석을 하였다.
안정성에 대해 말하자면..
우선 SysInternals라는 회사에 대해 말하고 싶다. 이 회사는 Filemon, Regmon과 같은 응용 프로그램을 제작하였으며, 만약 Windows Device Driver를 개발하면서 SysInternals를 못들어봤다면.. 간첩이라 할 수 있다. 안정성과 성능은 전세계인이 사용중이므로 패스~
(몇년째 사용했지만 port가 열렸는데 안나온다거나, 패킷이 전송될 때 connection이 안나오거나 하는 경우는 전혀 없었다)


다음은 분석 결과이다.

이것은 아무것도 안한 상태


HTML 페이지를 호출할 때를 보자.

* 크기가 24,159,200 Byte인 HTML 문서에 접속 할 경우 (1개의 connection)
보통 HTML 문서는 아주 잠시동안 로딩되므로 일부러 엄청난 크기의 HTML 문서를 만들었다.
내용은 별거 없다. 모두 주석처리 되어 있다.
보다싶이 1개의 connection 발견.



* 크기가 4,840,000 인 js 파일을 15개 포함하는 HTML 문서에 접속 할 경우
아래와 같은 코드를 포함하는 문서에 접속을 한다.

<script src="1.js"></script>
<script src="2.js"></script>
<script src="3.js"></script>
<script src="4.js"></script>
<script src="5.js"></script>
<script src="6.js"></script>
<script src="7.js"></script>
<script src="8.js"></script>
<script src="9.js"></script>
<script src="10.js"></script>
<script src="11.js"></script>
<script src="12.js"></script>
<script src="13.js"></script>
<script src="14.js"></script>
<script src="15.js"></script>


순서대로 받아진다. (초록색이 새로 생성된 connection이고 빨간색이 connection이 해제된 모습)

* 크기가 1,550,742 인 gif 파일을 19개 포함하는 HTML 문서에 접속 할 경우
다음과 같이 각각의 크기가 1,550,742인 19개의 그림파일이 포함된 문서에 접속을 한다.

<img src="1.gif"><br>
<img src="2.gif"><br>
<img src="3.gif"><br>
<img src="4.gif"><br>
<img src="5.gif"><br>
<img src="6.gif"><br>
<img src="7.gif"><br>
<img src="8.gif"><br>
<img src="9.gif"><br>
<img src="10.gif"><br>
<img src="11.gif"><br>
<img src="12.gif"><br>
<img src="13.gif"><br>
<img src="14.gif"><br>
<img src="15.gif"><br>
<img src="16.gif"><br>
<img src="17.gif"><br>
<img src="18.gif"><br>
<img src="19.gif"><br>


아래와 같이 동시다발적으로 connection이 생성되는 것을 볼 수 있다.
(정확히 20개는 아니다. 이것은 측정할때마다 달라지지만, HTML 로딩 및 파싱 후 GIF를 로딩하기 때문에 기본적으로 생길 수 있는 최대 connection의 수는 1+gif파일의 개수로 나타낼 수 있다.)


결론을 내려 blankus님이 질문하셨던 내용에 답을 하자면,

>> 여기서 의문점이 있습니다.
>> 1. html갯수 + 이미지의 갯수 = 커넥션의 갯수
>>  --> 이미지가 총 100개라면 커넥션의 갯수가 총 101개가 되는 논리입니다만, 정확한 근거가 무엇인지 궁금합니다.

정확히는 "connection의 최대 개수" 라고 할 수 있습니다. blankus님께서 테스트 한 결과는, gif의 크기가 작기때문에 connection의 동시 개수가 작아보인다고 할 수 있습니다. 또한 서버의 상황에 따라서 connect 되는 시간차가 있기 때문에, 단순한 ms차이로 동시에 다운로드 한다고 할 수 없습니다. 다음 항목을 connect할 때 이미 기존의 gif들이 다운로드 완료되어 동시에 처리되는 개수가 작아보일 수 있다는 것이구요.

>> 2. browser 내부에서는 별도의 파일 다운로드 관련 thread(일의 단위)가 생성
>>  --> winInet에 의해 서버당 http connection의 갯수가 제한됩니다.
>> Microsoft 참조글

문서에서는 "HttpSendRequest 및 InternetOpenURL"에 대해 언급되어 있습니다. Browser가 HttpSendRequest()라는 API를 이용하도록 작성되었다면, 저렇게 동작을 할 가능성이 있지만, 최소한 IE에서는 저 API를 사용하지 않는것으로 보이며, 80번 포트로 바로 접속해서 결과를 얻어오고 파싱한다고 유추해 낼 수 있습니다.

다른 browser에서는 다르지 않겠냐.. 하실텐데, 과연 성능이 떨어질만한.. 저 API를 사용할까요? :)
제가 FF 개발자라면 사용하지 않습니다~_~ 직접 80번 포트로 접속해서 일을 처리하도록 하죠. Windows API는 제약사항이 많거든요. 저 또한 HttpSendRequest() 라는 API는 잘 사용하지 않습니다. 전에 프로젝트 개발할때도 제약사항 및 성능, SSL의 지원등이 엉망이라.. 직접 모듈을 개발하였습니다.

P.S. 추가하자면 IE에서 동시 다운로드 개수 제한을 풀때는 저 문서에 있는

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\MaxConnectionsPerServer

의 수를 지정해 주기도 합니다.^^ 이 부분은 저 API를 사용하거나, 사용하지는 않지만 놔둔 옵션같네요.
왜 이렇게 했는지는 개발자 마음 같습니다.
(위의 결과에서 보시다싶이, IE에서 저 API를 사용하지 않는것 같군요)

P.S. #2 wininet은 저 API를 제공하는 dll 입니다. 보통 API를 사용하지 않고 소켓 통신을 할때는 winsock.dll을 사용합니다.


=======================
2007-08-06: 여러 PC에 확인 결과 위 결과는 제가 틀렸음을 밝힙니다. IE에서 HTTP Connection은 저 레지스트리 값을 따라갑니다. (FF제외) 저희집 PC가 왜 저런 결과를 뱉었는지 모르겠군요. IE7로 업그레이드 한 지금은 아무런 문제가 없습니다. :)
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by 장현준

2007/07/22 22:54 2007/07/22 22:54
,
Response
No Trackback , 2 Comments
RSS :
http://b4you.net/blog/rss/response/124

html 컨트롤 disable 시키기

<input type="checkbox" disabled="disabled">체크1
<input type="checkbox">체크2


와 같이 해주면 된다.

체크1
체크2
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by 장현준

2007/01/27 20:28 2007/01/27 20:28
Response
No Trackback , 2 Comments
RSS :
http://b4you.net/blog/rss/response/57

가끔 웹페이지에서 보다 보면 checkbox 옆에 있는 텍스트를 클릭했는데 같이 checkbox가 눌러지는 경우가 있다.

일반적으로 <tag value="<TEXT>"> 와 같이 표현을 하지만..

이것은 다음과 같은 HTML 태그에 의해서 손쉽게 해결할 수 있다.

<input type="checkbox" name="cb" id="cb"><label for="cb">눌러주세요</label>


크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by 장현준

2007/01/27 17:41 2007/01/27 17:41
,
Response
No Trackback , No Comment
RSS :
http://b4you.net/blog/rss/response/56


블로그 이미지

빗소리를 먹는 사람.

- 장현준

Notices

Archives

Authors

  1. 장현준

Recent Trackbacks

Calendar

«   2017/09   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Site Stats

Total hits:
1714552
Today:
3707
Yesterday:
3980