target 속성 a태그 브라우저 창 (window) 제어 방법
traget 속성에 대해서 알아봅시다.
기본적으로 쓰이는 내용들입니다.
target=”_blank” <– 새창
target=”_top” <– 브라우저전체
target=”_parent” <– 부모프레임
target=”_self” <– 현재프레임
생각이 가끔 잘안날때 들어와서 봐야겠네요 ㅋ
HTTP 프로토콜 이해
traget 속성에 대해서 알아봅시다.
기본적으로 쓰이는 내용들입니다.
target=”_blank” <– 새창
target=”_top” <– 브라우저전체
HTTP
에러코드 |
에러 메시지 |
100 | Continue |
101 | Switching Protocols |
200 | OK, 에러 없이 전송 성공 |
202 | Accepted, 서버가 클라이언트의 명령을 받음 |
203 | Non-authoritative Information, 서버가 클라이언트 요구 중 일부만 전송함 |
204 | Non Content, 클라이언트 요구를 처리했으나 전송할 데이터가 없음 |
205 | Reset Content |
206 | Partial Content |
300 | Multiple Choices, 최근에 옮겨진 데이터를 요청함. |
301 | Moved Permanently, 요구한 데이터를 변경된 임시 URL에서 찾음 |
302 | Moved Permanently, 요구한 데이터가 변경된 URL에 있음 |
303 | See Other, 요구한 데이터를 변경하지 않았기 때문에 문제가 있음 |
304 | Not modified |
305 | Use Proxy |
400 | Bad Request, 요청 실패 – 문법상 오류가 있어서 서버가 요청 사항을 이해하지 못함. |
401.1 | Unauthorized, 권한 없음 – 접속 실패, 이 에러는 서버에 로그온 하려는 요청 사항이 서버에 들어있는 권한과 비교했을 시 맞지 않을 경우 발생. 이 경우, 요청한 자원에 접근할 수 있는 권한을 부여받기 위해서 서버 운영자에게 요청해야 함. |
401.2 | Unauthorized, 권한 없음 – 서버 설정으로 인한 접속 실패, 이 에러는 서버에 로그온 하려는 요청사항이 서버에 들어있는 권한과 비교했을 때 맞지 않을 경우 발생. 이것은 일반적으로 적절한 www-authenticate head field를 전송하지 않아서 발생함. |
402.3 | Unauthorized, 권한 없음 – 자원에 대한 ACL에 기인한 권한 없음. 이 에러는 클라이언트가 특정 자원에 접근할 수 없을 때 발생. 이 자원은 페이지가 될 수도 있고, 클라이언트의 주소 입력란에 명기된 파일일 수도 있다. 또한, 클라이언트가 해당 주소로 접속할 때 이용되는
또 다른 파일일 수도 있다. 접근할 전체 주소를 다시 확인해 보고 웹 서버 운영자에게 여러분이 자원에 접근할 권한이 있는지를 확인한다. |
401.4 | Unauthorized, 권한 없음 – 필터에 의한 권한 부여 실패. 이 에러는 웹 서버가 서버에 접속하는 사용자들을 확인하기 위해 설치한 필터 프로그램이 있음을 의미함. 서버에 접속하는데 이용되는 인증 과정이 이런 필터 프로그램에 의해 거부된 것임 |
404.5 | Unauthorized, 권한 없음 – ISA PI/CGI 어플리케이션에 의한 권한 부여 실패. 이 에러는 이용하려는 웹 서버의 어드레스에 ISA PI나 CGI 프로그램이 설치되어 있어 사용자의 권한을 검증함. 서버에 접속하는데 이용되는 인증 과정이 이 프로그램에 의해 거부됨. |
402 | Payment Required, 예약됨 |
403.1 | Forbidden, 금지 – 수행 접근 금지. 이 에러는 CGI나 ISA-PI, 혹은 수행시키지 못하도록 되어 있는 디렉터리 내의 실행 파일을 수행시키려고 했을 때 발생함. |
403.2 | Forbidden, 금지 – 읽기 접근 금지. 이 에러는 브라우저가 접근한 디렉터리에 가용한 디폴트 페이지가 없을 경우에 발생함. |
403.4 | Forbidden, 금지 – SSL 필요. 이 에러는 접근하려는 페이지가 SSL로 보안 유지되고 있는 것일 때 발생. |
403.5 | Forbidden, 금지 – SSL 128이 필요. 이 에러는 접근하려는 페이지가 SSL로 보안 유지되고 있는 것일 때 발생. 브라우저가 128비트의 SSL을 지원하는지를 확인해야 함. |
403.6 | Forbidden, 금지 – IP 주소 거부됨. 이 에러는 서버가 사이트에 접근이 허용되지 않은 IP주소로 사용자가 접근하려 했을 때 발생함. |
403.7 | Forbidden, 금지 – 클라이언트 확인 필요. 이 에러는 접근하려는 자원이 서버가 인식하기 위해서 브라우저에게 클라이언트 SSL을 요청하는 경우 발생함. 자원을 이용할 수 있는 사용자임을 입증하는데 사용됨. |
403.8 | Forbidden, 금지 – 사이트 접근 거부. 이 에러는 웹 서버가 요청사항을 수행하고 있지 않거나, 해당 사이트에 접근하는 것을 허락하지 않았을 경우에 발생함. |
403.9 | Forbidden, 금지 – 연결된 사용자수 과다. 이 에러는 웹 서버가 busy한 상태에 있어서 요청을 수행할 수 없을 경우에 발생함. |
403.10 | Forbidden, 금지 – 설정이 확실하지 않음. 이 에러는 웹 서버의 설정 부분에 문제가 있을 경우 발생함. |
403.11 | Forbidden, 금지 – 패스워드 변경. 이 에러는 사용자 인증 단계에서 잘못된 패스워드를 입력했을 경우 발생함. |
403.12 | Forbidden, 금지 – Mapper 접근 금지. 이 에러는 클라이언트 인증용 맵(map)이 해당 웹 사이트에 접근하는 것을 거부할 경우에 발생. |
404 | Not Found, 문서를 찾을 수 없음 – 이 에러는 클라이언트가 요청한 문서를 찾지 못한 경우에 발생함. URL을 다시 잘 보고 주소가 올바로 입력되었는지를 확인함. |
405 | Method not allowed, 메소드 허용 안 됨 – 이 에러는 Request 라인에 명시된 메소드를 수행하기 위한 해당 자원의 이용이 허용되지 않았을 경우에 발생함. |
406 | Not Acceptable, 받아들일 수 없음 – 이 에러는 요청 사항에 필요한 자원은 요청 사항으로 전달된 Accept header에 따라 “Not Acceptable” 내용을 가진 사항이 있을 경우에 발생함. |
407 | Proxy Authentication Required, Proxy 인증이 필요함 – 이 에러는 해당 요청이 수행되도록 proxy 서버에게 인증을 받아야 할 경우에 발생함. |
408 | Request timeout, 요청 시간이 지남 |
409 | Conflict |
410 | Gone, 영구적으로 사용할 수 없음. |
411 | Length Required |
412 | Precondition Failed, 선결조건 실패 – 이 에러는 Request-header filed에 하나 이상에 선결 조건에 대한 값이 서버에서의 테스트 결과 false로 나왔을 경우에 발생 |
413 | Request entity too large |
414 | Request-URI too long, 요청한 URI가 너무 김 – 이 에러는 요청한 URI의 길이가 너무 길어서 서버가 요청 사항의 이행을 거부했을 경우 발생 |
415 | Unsupported media type |
500 | Internal Server Error, 서버 내부 오류 – 이 에러는 웹 서버가 요청사항을 수행할 수 없을 경우에 발생함 |
501 | Not Implemented, 적용 안 됨 – 이 에러는 웹 서버가 요청사항을 수행하는데 필요한 기능을 지원하지 않는 경우에 발생 |
502 | Bad gateway, 게이트웨이 상태 나쁨 – 이 에러는 게이트웨이 상태가 나쁘거나 서버의 과부하 상태일 때 발생한다. |
503 | Service Unavailable, 서비스 불가능 – 이 에러는 서비스가 현재 멈춘 상태 또는 현재 일시적인 과부하 또는 관리 상황일 때 발생될 수 있다. |
504 | Gateway timeout |
505 | HTTP Version Not Supported |
HTTP 요청/응답 스펙 간략히 이해하기 최근 La Scala 코딩단에서 Scala로 정적서버를 구현하는 스터디를 진행하게 되면서 HTTP 스펙을 다시 보게되었다. 웹개발을 하다보니 HTTP 프로토콜을 많이 사용해서 익숙하기는 하지만 그렇다고 스펙을 찬찬히 본적은 없었기에 이번 기회를 삼아서 스펙을 좀 살펴보았고 HTTP 스펙을 잘 아시는 셈틀노리님의 설명도 들었다. HTTP 1.1의 스펙은 IETF에 잘 나와있다. 일반적으로 웹프레임워크에서 대부분 처리해줘서 직접 헤더를 다뤄본 적은 없기 때문에 스터디의 범위에는 포함되어 있지 않았지만 HTTP 스펙을 좀 이해해보자는 차원에서 헤더 파싱도 간단하게 나마 시도해 봤었다. 스펙의 양이 아주 많지는 않은데 그렇다고 다 읽어본 것은 아니고 필요한 부분만 좀 찾아보았는데 셈틀노리님이 정리해서 설명도 해주었기 때문에 간단하게 나마 정리한다. Request 요청 메시지는 스펙상 다음과 같이 생겼다. Request-Line *(( general-header | request-header | entity-header ) CRLF) CRLF [ message-body ] 간단히 말하면 첫줄은 Request-Line이 오고 이어서 여러 종류의 헤더가 나온 다음에 줄바꿈을 두번하고(한줄 건너띄고) 메시지 바디가 오게된다. Request Line 요청의 첫 줄은 Request Line이라고 부르는데 스펙상은 Method SP Request-URI SP HTTP-Version CRLF 와 같이 정의하는데 보통 다음과 같이 생겼다. GET /index.html HTTP/1.1 맨 앞의 GET은 요청 Method를 의미하는데 OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT 8가지가 있다. OPTIONS : 요청 URI에서 사용할 수 있는 Method를 물어본다.(스펙 참고) GET : 요청 URI의 정보를 가져온다.(스펙 참고) HEAD : GET 요청에서 body는 제외하고 헤더만 가져온다.(스펙 참고) POST : 요청 URI의 리소스의 새로운 정보를 보낸다.(스펙 참고) PUT : 요청 URI에 저장될 정보를 보낸다. (스펙 참고) DELETE : 요청 URI의 리소스를 삭제한다.(스펙 참고) TRACE : 보낸 메시지를 다시 돌려보낸다. (스펙 참고) CONNECT : 프록시에 사용하기 위해 예약된 메서드이다.(스펙 참고) 메서드 다음에는 요청 URI가 온다.(/index.html 부분) 말그대로 URI이고 절대경로의 URI가 될수도 있고 *이 될수도 있다. Request Line의 마지막에는 HTTP 버전을 의히한다. 스펙상으로는 &quot;HTTP&quot; &quot;/&quot; 1*DIGIT &quot;.&quot; 1*DIGIT 와 같이 정의되는데 현재 HTTP/1.0과 HTTP/1.1이 있다. 마지막에는 &lt;CRLF&gt;가 있어야 한다. 즉, 줄바꿈을 한다는 얘기인데 CR은 carriage return(13)이고 LF는 linefeed(10)이다.(각 기호에 대한 정의는 스펙의 Basic Rule부분에 나와있다.) 추가: 김관래의 제보로 PATCH 메서드 추가합니다. partial resource modification 용도라는데 HTTP 1.1 스펙에 안들어있는걸 보면 진행중인 상태가 아닐까 혼자 추측해 봅니다. PATCH for HTTP Headers Request-Line 다음에는 header가 위치하는데 앞에서 본 스펙대로 general-header, request-header, entity-header 3가지 종류가 있고 요청에 따라 필요한 헤더만 사용하게 된다. General Header에는 Cache-Control, Connection, Date, Pragma, Trailer, Transfer-Enco, Upgrade, Via, Warning가 있고 Request Header에는 Accept, Accept-Charset, Accept-Encoding, Accept-Language, Authorization, Expect, From, Host, If-Match, If-Modified-Since, If-None-Match, If-Range, If-Unmodified-Since, Max-Forwards, Proxy-Authorization, Range, Referer, TE, User-Agent등이 있고 Entity Header에는 Allow, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type, Expires, Last-Modified, extension-header가 있다. 헤더는 name : content의 형식이 되는데 content 부분은 각 헤더에 대한 상세 내용을 확인해 보면 되는데 각 값들은 공백이나 탭으로 구분될 수 있고 각 헤더는 CRLF로 구분된다. Response 응답 메시지는 다음과 같이 정의되어 있다. Status-Line *(( general-header | response-header | entity-header ) CRLF) CRLF [ message-body ] 첫줄이 요청라인대신에 상태라인인것과 요청헤더 대신 응답헤더가 들어간 것만 빼면 요청 메시지와 동일한 형태이다. Status Line Status Line은 HTTP-Version SP Status-Code SP Reason-Phrase CRLF로 정의되어 있고 보통 다음과 같이 생겼다. HTTP/1.1 200 OK HTTP 버전은 요청부분에서 설명한 것과 동일하고 상태코드(Status-Code)는 흔히 보는 3자리 숫자로 된 상태를 나타내는 코드로 각 번호대 별로 다음과 같은 의미를 가지고 있다. 1xx : 정보성 2xx : 성공 3xx : 리다이렉트 4xx : 클라이언트 오류 5xx : 서버 오류 각 상태코드에 대한 설명도 스펙에 잘 나와있다. Headers 헤더 부분의 General Header와 Entity Header는 요청부분에서 설명한 것과 동일하고 Response Header는 Accept-Ranges, Age, ETag, Location, Proxy-Authenticate, Retry-After, Server, Vary, WWW-Authenticate가 있다.