HTTP 편집하기
최신판 | 당신의 편집 | ||
1번째 줄: | 1번째 줄: | ||
− | '''HTTP'''(에이치티티피)는 | + | '''HTTP'''(에이치티티피)는 Hypertext Transfer Protocol의 약자로서, 월드 와이드 웹(WWW: World Wide Web)을 이용하여 [[HTML]]로 작성된 [[하이퍼텍스트]] 문서를 주고받을 수 있는 [[프로토콜]]이다. HTTP 통신규약을 이용하여 [[웹서버]]와 [[웹브라우저]] 사이에서 정보를 주고받을 수 있다. [[포트]] 번호는 80번이다. '''에이치티티피'''라고 읽는다. 보통 "http://"와 같이 소문자로 쓴다. |
==개요== | ==개요== | ||
− | HTTP는 | + | HTTP는 웹 상에서 [[클라이언트]]와 서버 간에 통신을 위해 개발된 [[프로토콜]]이다. [[웹]](Web)의 정식 명칭은 월드 와이드 웹으로 전 세계에 거미줄처럼 연결된 망이라는 뜻이다. 다양한 [[하이퍼 텍스트]](Hyper Text) 문서들이 웹 상에서 서로 연결되어 있다. 하이퍼 텍스트 문서란 참조 혹은 링크를 통해 한 문서에서 다른 문서로 접근할 수 있는 문서를 말한다. 대표적인 하이퍼 텍스트 문서로 HTML이 있다. 주로 80/tcp 포트를 사용하며 1991년 초기버전(0.9)이 발표된 이후 1996년 1.0버전, 1999년 1.1버전이 발표되어 널리 사용되고 있다. |
− | + | HTTP 통신은 클라이언트 요청(Request)과 서버 응답(Response)으로 이루어져 있다. HTTP/1.1 버전부터 Connection 헤더에 Keep-Alive 옵션이 추가되었다, 이는 TCP 연결 상태를 웹 서버 설정에 따라 일정시간 지속시키는 옵션으로 한 번의 연결 이후에 요청/응답을 반복할 수 있다. HTTP 응답 메시지를 분석해보면, 일반적으로 이미지, 스크립트 등 다수의 추가 자원 요청이 발생한다. 따라서 TCP 연결 설정 및 종료에 대한 부하를 줄이면서 효율적으로 클라이언트 요청을 처리하기 위해 연결 상태를 일정시간 유지하는 옵션이 추가되었다.<ref>공대냥이, 〈[https://helloworld-88.tistory.com/38 IT 용어 정리 - HTTP 란?]〉, 《티스토리》, 2018-10-19</ref> | |
− | |||
==역사== | ==역사== | ||
− | *1965년 : 제너두 | + | *1965년 : 제너두 프로젝트에서 [[테드 넬슨]]에 의해 하이퍼텍스트라는 용어가 만들어졌으며, 제너두 프로젝트는 'As We May Think(1945년)'라는 수필에서 마이크로필름 기반 정보 수신 및 관리 "메멕스" 시스템을 기술한 버니바 부시의 비전(1930년대)에 의해 영감을 받았다. |
− | *1989년 : [[팀 버너스 리]] | + | *1989년 : [[팀 버너스 리]]와 그의 팀은 CERN에서 [[HTML]]뿐 아니라 [[웹 브라우저]] 및 텍스트 기반 웹 브라우저 관련 기술과 더불어 오리지널 HTTP을 발명하였다. 버너스 리는 최초로 "월드와이드웹" 프로젝트를 제안하였으며, 이것이 현재의 월드 와이드 웹이다. 이 [[프로토콜]]의 최초 버전은 서버로부터 페이지를 요청하는 GET이라는 이름의 하나의 메소드만 있었다. 서버로부터의 응답은 무조건 HTML 문서였다. |
− | *1991년 : 문서화된 최초의 HTTP 버전은 HTTP V0. | + | *1991년 : 문서화된 최초의 HTTP 버전은 HTTP V0.9(1991년)이다. |
− | *1995년 : [[데이브 레겟]] | + | *1995년 : [[데이브 레겟]]은 HTTP 워킹 그룹(HTTP WG)을 이끌었으며 확장된 조작, 확장된 협상, 더 보강된 메타 정보, 또 추가 메소드와 헤더 필드를 통한 더 효율적인 보안 프로토콜을 갖춘 프로토콜을 확장하기를 바랐다. |
*1995년 12월 : HTTP WG는 새로운 표준을 출간하기로 계획하였으며 당시 개발 중인 RFC 2068(이른바 HTTP-NG)에 기반한 이전 표준 HTTP/1.1에 대한 지원이 1996년 초에 주요 브라우저 개발자들에 의해 빠르게 채택되었다. | *1995년 12월 : HTTP WG는 새로운 표준을 출간하기로 계획하였으며 당시 개발 중인 RFC 2068(이른바 HTTP-NG)에 기반한 이전 표준 HTTP/1.1에 대한 지원이 1996년 초에 주요 브라우저 개발자들에 의해 빠르게 채택되었다. | ||
*1996년 : RFC 1945는 공식적으로 HTTP v1.0을 도입하였다. | *1996년 : RFC 1945는 공식적으로 HTTP v1.0을 도입하였다. | ||
− | *1996년 | + | *1996년 3월 : 이전 표준 HTTP/1.1을 지원한 웹 브라우저로 아레나, 넷스케이프 2.0, 넷스케이프 내비게이터 골드 2.01, 모자이크 2.7, 링크스 2.5, 인터넷 익스플로러 2.0이 있다. 새로운 브라우저의 최종 사용자 채택 속도를 빨랐다. |
− | *1996년 | + | *1996년 3월 : 한 웹 호스팅 회사의 보고에 따르면 인터넷 상에서 사용 중인 브라우저 중 40% 이상이 HTTP 1.1과 호환되었다. 같은 웹 호스팅 회사는 1996년 6월 기준으로 서버에 접근하는 모든 브라우저들 가운데 65%가 HTTP/1.1 호환이라고 보고하였다. |
− | *1997년 | + | *1997년 1월 : RFC 2068에 정의된 HTTP/1.1 표준이 공식적으로 출시되었다. |
− | *1999년 | + | *1999년 6월 : HTTP/1.1 표준에 대한 개선과 업데이트가 RFC 2616으로 출시되었다. |
*2007년 : 부분적으로 HTTP/1.1 사양을 개정하고 분명히 하기 위해 HTTPbis 워킹 그룹이 창설되었다. | *2007년 : 부분적으로 HTTP/1.1 사양을 개정하고 분명히 하기 위해 HTTPbis 워킹 그룹이 창설되었다. | ||
− | *2014년 | + | *2014년 6월 : WG는 RFC 2616를 obsolete 처리하는, 업데이트된 6 파트 사양을 출시하였다. |
− | *2015년 | + | *2015년 5월 : HTTP/2가 RFC 7540로 출판되었다.<ref name="위키백과">HTTP 위키백과 - https://ko.wikipedia.org/wiki/HTTP</ref> |
==특징== | ==특징== | ||
− | + | *TCP/IP를 이용하는 [[응용 프로토콜]](application protocol) 이다. 컴퓨터와 컴퓨터간에 데이터를 전송 할 수 있도록 하는 장치로 [[인터넷]]을 통해 원하는 정보를 주고 받는 기능을 이용하는 응용 프로콜로 포트 번호는 기본적으로 80번을 사용한다. | |
− | + | * HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜이다. 예를 들면 브라우저를 통해 사용자의 요청(Request)에 따라 서버와 접속하여 요청에 대한 응답(Response)의 데이터를 전송 후 연결 종료한다. 이러한 심플한 상태이기 때문에 전산 자원이 적게 든다는 장점이 있다. 하지만, 연결이 지속적이지 않기에 사용자와 종료 후 추가적인 요청을 처리할 수 없다는 단점이 있다. 이런 단점을 해소하기 위한 방법으로 Cookie, Session, URL Rewriting, Hidden Form Field 등이 사용된다. 참고로 HTTP와 반대로 연결 상태 유지하는 프로토콜은 FTP, [[Telnet]]이 있다. | |
+ | *HTTP는 연결 상태를 유지하지 않는 프로토콜이기 때문에 요청(Request)/응답(Response)방식으로 동작한다. 서버가 먼저 응답하지 않으며 사용자의 요청 한개에 대해 한개의 응답을 하는 방식이다.<ref>달나라 곰돌이, 〈[https://helloworld-88.tistory.com/38 (기본)HTTP란?]〉, 《헬로우월드》, 2018-07-18</ref> | ||
− | + | ==동작방식== | |
+ | HTTP는 연결 상태를 유지하지 않는 [[프로토콜]]이기 때문에 요청/응답(request/response)방식으로 동작한다. | ||
− | + | #클라이언트 연결 | |
+ | #클라이언트 측 브라우저에서 [[웹 리소스]]를 얻기 위해 브라우저에서 URL 발급 | ||
+ | #HTTP Request | ||
+ | #서버에서 Request 메세지를 해석하고 사용자에게 요청한 자원 오류 메세지 등의 적절한 Http Response 반환 | ||
− | + | ==메시지 포맷== | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | 클라이언트와 서버 사이의 소통은 평문(ASCII) 메시지로 이루어진다. 클라이언트는 서버로 요청메시지를 전달하며 서버는 응답메시지를 보낸다. | |
− | |||
− | + | ===요청 메시지=== | |
+ | *요청 내용 | ||
+ | 보기) GET /images/logo.gif HTTP/1.1 | ||
+ | *헤더 | ||
+ | 보기) Accept-Language: en | ||
+ | *빈 줄 (empty line) | ||
+ | *기타 메시지를 포함하여 표시된다. | ||
+ | 요청 내용과 헤더 필드는 <CR><LF>로 끝나야 한다. 즉, 캐리지 리턴(Carriage Return) 다음에 라인 피드(Line Feed)가 와야 한다. 빈 줄(empty line)은 <CR><LF>로 구성되며 그 외 다른 화이트스페이스(whitespace)가 있어서는 안된다. | ||
− | + | :{|class=wikitable width=600 | |
− | !align=center | + | |+<big>'''요약표'''</big> |
− | !align=center | + | !align=center|HTTP 메소드 |
− | !align=center | + | !align=center|RFC |
− | !align=center | + | !align=center|요청에 Body가 있음 |
− | !align=center | + | !align=center|응답에 Body가 있음 |
− | !align=center | + | !align=center|안전 |
− | !align=center | + | !align=center|멱등(Idempotent) |
+ | !align=center|캐시 가능 | ||
|- | |- | ||
|align=center|GET | |align=center|GET | ||
|align=center|RFC 7231 | |align=center|RFC 7231 | ||
− | |align=center | + | |align=center|아니오 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|예 |
|- | |- | ||
|align=center|HEAD | |align=center|HEAD | ||
|align=center|RFC 7231 | |align=center|RFC 7231 | ||
− | |align=center | + | |align=center|아니오 |
− | |align=center | + | |align=center|아니오 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|예 |
|- | |- | ||
|align=center|POST | |align=center|POST | ||
|align=center|RFC 7231 | |align=center|RFC 7231 | ||
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|아니오 |
− | |align=center | + | |align=center|아니오 |
− | |align=center | + | |align=center|예 |
|- | |- | ||
|align=center|PUT | |align=center|PUT | ||
|align=center|RFC 7231 | |align=center|RFC 7231 | ||
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|아니오 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|아니오 |
|- | |- | ||
|align=center|DELETE | |align=center|DELETE | ||
|align=center|RFC 7231 | |align=center|RFC 7231 | ||
− | |align=center | + | |align=center|아니오 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|아니오 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|아니오 |
|- | |- | ||
|align=center|CONNECT | |align=center|CONNECT | ||
|align=center|RFC 7231 | |align=center|RFC 7231 | ||
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|아니오 |
− | |align=center | + | |align=center|아니오 |
− | |align=center | + | |align=center|아니오 |
|- | |- | ||
|align=center|OPTIONS | |align=center|OPTIONS | ||
|align=center|RFC 7231 | |align=center|RFC 7231 | ||
− | |align=center | + | |align=center|선택 사항 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|아니오 |
|- | |- | ||
|align=center|TRACE | |align=center|TRACE | ||
|align=center|RFC 7231 | |align=center|RFC 7231 | ||
− | |align=center | + | |align=center|아니오 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|아니오 |
|- | |- | ||
|align=center|PATCH | |align=center|PATCH | ||
|align=center|RFC 5789 | |align=center|RFC 5789 | ||
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|예 |
− | |align=center | + | |align=center|아니오 |
− | |align=center | + | |align=center|아니오 |
− | |align=center | + | |align=center|예 |
|} | |} | ||
− | + | ===응답 메시지=== | |
+ | *상태표시 행(status line): 상태코드(status code)와 reason message를 포함한다. (예. HTTP/1.1 200 OK. 클라이언트의 요청이 성공적으로 전달되었음을 표시) | ||
+ | *응답 헤더필드 (예.Content-Type: text/html) | ||
+ | *빈 줄 (empty line) | ||
+ | *기타 메시지<ref name="위키백과"></ref> | ||
− | ===응답 | + | ==HTTP 응답코드== |
− | + | ===1xx (조건부 응답)=== | |
+ | 요청을 받았으며 작업을 계속한다. | ||
+ | 이 상태의 상태 코드는 상태-라인과 선택적 헤더(컴퓨터에서 출력될 때 각 페이지 맨 윗부분에 자동으로 붙는 부분)만을 포함하는 임시의 응답을 나타내고 빈 라인에 의해서 종결된다. HTTP/1.0이래로 어떤 1XX 상태 코드들도 정의 되지 않았다. 서버들은 1XX 응답을 실험적인 상태를 제외하고 HTTP/1.0 클라이언트(서버에 연결된 컴퓨터)로 보내면 안 된다. | ||
+ | *100(계속): 요청자는 요청을 계속해야 한다. 서버는 이 코드를 제공하여 요청의 첫 번째 부분을 받았으며 나머지를 기다리고 있음을 나타낸다. | ||
+ | *101(프로토콜 전환): 요청자가 서버에 프로토콜 전환을 요청했으며 서버는 이를 승인하는 중이다. | ||
+ | *102(처리, RFC 2518) | ||
− | === | + | ===2xx (성공)=== |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
이 클래스의 상태 코드는 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다. | 이 클래스의 상태 코드는 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다. | ||
+ | *200(성공): 서버가 요청을 제대로 처리했다는 뜻이다. 이는 주로 서버가 요청한 페이지를 제공했다는 의미로 쓰인다. | ||
+ | *201(작성됨): 성공적으로 요청되었으며 서버가 새 리소스를 작성했다. | ||
+ | *202(허용됨): 서버가 요청을 접수했지만 아직 처리하지 않았다. | ||
+ | *203(신뢰할 수 없는 정보): 서버가 요청을 성공적으로 처리했지만 다른 소스에서 수신된 정보를 제공하고 있다. | ||
+ | *204(콘텐츠 없음): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않는다. | ||
+ | *205(콘텐츠 재설정): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 표시하지 않는다. 204 응답과 달리 이 응답은 요청자가 문서 보기를 재설정할 것을 요구한다(예: 새 입력을 위한 양식 비우기). | ||
+ | *206(일부 콘텐츠): 서버가 GET 요청의 일부만 성공적으로 처리했다. | ||
+ | *207(다중 상태, RFC 4918) | ||
+ | *208(이미 보고됨, RFC 5842) | ||
+ | *226 IM Used (RFC 3229) | ||
− | + | ===3xx (리다이렉션 완료)=== | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | ===3xx=== | ||
클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다. | 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다. | ||
− | + | *300(여러 선택항목): 서버가 요청에 따라 여러 조치를 선택할 수 있다. 서버가 사용자 에이전트에 따라 수행할 작업을 선택하거나, 요청자가 선택할 수 있는 작업 목록을 제공한다. | |
− | *300 | + | *301(영구 이동): 요청한 페이지를 새 위치로 영구적으로 이동했다. GET 또는 HEAD 요청에 대한 응답으로 이 응답을 표시하면 요청자가 자동으로 새 위치로 전달된다. |
− | *301 | + | *302(임시 이동): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다. |
− | *302 | + | *303(기타 위치 보기): 요청자가 다른 위치에 별도의 GET 요청을 하여 응답을 검색할 경우 서버는 이 코드를 표시한다. HEAD 요청 이외의 모든 요청을 다른 위치로 자동으로 전달한다. |
− | *303 | + | *304(수정되지 않음): 마지막 요청 이후 요청한 페이지는 수정되지 않았다. 서버가 이 응답을 표시하면 페이지의 콘텐츠를 표시하지 않는다. 요청자가 마지막으로 페이지를 요청한 후 페이지가 변경되지 않으면 이 응답(If-Modified-Since HTTP 헤더라고 함)을 표시하도록 서버를 구성해야 한다. |
− | *304 | + | *305(프록시 사용): 요청자는 프록시를 사용하여 요청한 페이지만 액세스할 수 있다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 하다. |
− | *305 | + | *307(임시 리다이렉션): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다. |
− | + | *308(영구 리다이렉션, RFC에서 실험적으로 승인됨) | |
− | *307 | ||
− | *308 | ||
===4xx (요청 오류)=== | ===4xx (요청 오류)=== | ||
− | 4xx 클래스의 상태 코드는 클라이언트에 오류가 있음을 나타낸다. | + | 4xx 클래스의 상태 코드는 클라이언트에 오류가 있음을 나타낸다. |
− | + | *400(잘못된 요청): 서버가 요청의 구문을 인식하지 못했다. | |
− | *400 | + | *401(권한 없음): 이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다. 상태 코드 이름이 권한 없음(Unauthorized)으로 되어 있지만 실제 뜻은 인증 안됨(Unauthenticated)에 더 가깝다. |
− | *401 | + | *402(결제 필요): 이 요청은 결제가 필요합니다. |
− | *402 | + | *403(Forbidden, 금지됨): 서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을 갖고 있지 않다. (401은 인증 실패, 403은 인가 실패라고 볼 수 있음) |
− | *403 Forbidden | + | *404(Not Found, 찾을 수 없음): 서버가 요청한 페이지(Resource)를 찾을 수 없다. 예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다. |
− | *404 Not Found | + | *405(허용되지 않는 방법): 요청에 지정된 방법을 사용할 수 없다. 예를 들어 POST 방식으로 요청을 받는 서버에 GET 요청을 보내는 경우, 또는 읽기 전용 리소스에 PUT 요청을 보내는 경우에 이 코드를 제공한다. |
− | *405 | + | *406(허용되지 않음): 요청한 페이지가 요청한 콘텐츠 특성으로 응답할 수 없다. |
− | *406 | + | *407(프록시 인증 필요): 이 상태 코드는 401(권한 없음)과 비슷하지만 요청자가 프록시를 사용하여 인증해야 한다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 한다. |
− | *407 | + | *408(요청 시간초과): 서버의 요청 대기가 시간을 초과하였다. |
− | *408 | + | *409(충돌): 서버가 요청을 수행하는 중에 충돌이 발생했다. 서버는 응답할 때 충돌에 대한 정보를 포함해야 한다. 서버는 PUT 요청과 충돌하는 PUT 요청에 대한 응답으로 이 코드를 요청 간 차이점 목록과 함께 표시해야 한다. |
− | *409 | + | *410(사라짐): 서버는 요청한 리소스가 영구적으로 삭제되었을 때 이 응답을 표시한다. 404(찾을 수 없음) 코드와 비슷하며 이전에 있었지만 더 이상 존재하지 않는 리소스에 대해 404 대신 사용하기도 한다. 리소스가 영구적으로 이동된 경우 301을 사용하여 리소스의 새 위치를 지정해야 한다. |
− | *410 | + | *411(길이 필요): 서버는 유효한 콘텐츠 길이 헤더 입력란 없이는 요청을 수락하지 않는다. |
− | *411 | + | *412(사전조건 실패): 서버가 요청자가 요청 시 부과한 사전조건을 만족하지 않는다. |
− | *412 | + | *413(요청 속성이 너무 큼): 요청이 너무 커서 서버가 처리할 수 없다. |
− | *413 | + | *414(요청 URI가 너무 긺): 요청 URI(일반적으로 URL)가 너무 길어 서버가 처리할 수 없다. |
− | *414 | + | *415(지원되지 않는 미디어 유형): 요청이 요청한 페이지에서 지원하지 않는 형식으로 되어 있다. |
− | *415 | + | *416(처리할 수 없는 요청범위): 요청이 페이지에서 처리할 수 없는 범위에 해당되는 경우 서버는 이 상태 코드를 표시한다. |
− | *416 | + | *417(예상 실패): 서버는 Expect 요청 헤더 입력란의 요구사항을 만족할 수 없다. |
− | *417 | + | *418(I'm a teapot, RFC 2324 ,https://google.com/teapot) |
− | *418 I'm a teapot | + | *420(Enhance Your Calm, 트위터) |
− | *420 (Enhance Your Calm, 트위터) | + | *422(처리할 수 없는 엔티티, WebDAV; RFC 4918) |
− | + | *423(잠김,WebDAV; RFC 4918): 접근하려는 리소스가 잠겨 있다. | |
− | *422 | + | *424(실패된 의존성, WebDAV; RFC 4918) |
− | *423 | + | *424(메쏘드 실패, WebDAV) |
− | *424 | + | *425(정렬되지 않은 컬렉션, 인터넷 초안) |
− | *424 ( | + | *426(업그레이드 필요, RFC 2817): 클라이언트는 업그레이드 헤더 필드에 주어진 프로토콜로 요청을 보내야 한다. |
− | *425 | + | *428(전제조건 필요, RFC 6585) |
− | *426 | + | *429(너무 많은 요청, RFC 6585): 사용자가 일정 시간 동안 너무 많은 요청을 보냈다. |
− | *428 | + | *431(요청 헤더 필드가 너무 큼, RFC 6585) |
− | *429 | + | *444(응답 없음, Nginx) |
− | *431 | + | *449(다시 시도, 마이크로소프트) |
− | *444 (응답 없음, Nginx) | + | *450(윈도 자녀 보호에 의해 차단됨, 마이크로소프트) |
− | *449 (다시 시도, 마이크로소프트) | + | *451(법적인 이유로 이용 불가, 인터넷 초안) |
− | *450 (윈도 자녀 보호에 의해 차단됨, 마이크로소프트) | + | *451(리다이렉션, 마이크로소프트) |
− | *451 | + | *494(요청 헤더가 너무 큼, Nginx) |
− | *451 (리다이렉션, 마이크로소프트) | + | *495(Cert 오류, Nginx) |
− | *494 (요청 헤더가 너무 큼, Nginx) | + | *496(Cert 없음, Nginx) |
− | *495 (Cert 오류, Nginx) | + | *497(HTTP to HTTPS, Nginx) |
− | *496 (Cert 없음, Nginx) | + | *499(클라이언트가 요청을 닫음, Nginx) |
− | *497 (HTTP to HTTPS, Nginx) | ||
− | *499 (클라이언트가 요청을 닫음, Nginx) | ||
===5xx (서버 오류)=== | ===5xx (서버 오류)=== | ||
서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다. | 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다. | ||
+ | 500(내부 서버 오류): 서버에 오류가 발생하여 요청을 수행할 수 없다. | ||
+ | 501(구현되지 않음): 서버에 요청을 수행할 수 있는 기능이 없다. 예를 들어 서버가 요청 메소드를 인식하지 못할 때 이 코드를 표시한다. | ||
+ | 502 (Bad Gateway, 불량 게이트웨이): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 잘못된 응답을 받았다. | ||
+ | 503(서비스를 사용할 수 없음): 서버가 오버로드되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할 수 없다. 이는 대개 일시적인 상태이다. | ||
+ | 504(게이트웨이 시간초과): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 제때 요청을 받지 못했다. | ||
+ | 505(HTTP 버전이 지원되지 않음): 서버가 요청에 사용된 HTTP 프로토콜 버전을 지원하지 않는다. | ||
+ | 506(Variant Also Negotiates, RFC 2295) | ||
+ | 507(용량 부족, WebDAV; RFC 4918) | ||
+ | 508(루프 감지됨, WebDAV; RFC 5842) | ||
+ | 509(대역폭 제한 초과, Apache bw/limited extension) | ||
+ | 510(확장되지 않음, RFC 2774) | ||
+ | 511(네트워크 인증 필요, RFC 6585) | ||
+ | 520(Unknown Error, 알 수 없음) | ||
+ | 598(네트워크 읽기 시간초과 오류, 알 수 없음) | ||
+ | 599(네트워크 연결 시간초과 오류, 알 수 없음)<ref name"위키백과">HTTP 상태 코드 위키백과 - https://ko.wikipedia.org/wiki/HTTP_상태_코드</ref> | ||
− | + | ==HTTPS== | |
− | + | HTTPS는 월드 와이드 웹 통신(WWW) 프로토콜인 HTTP의 보안이 강화된 버전이다. HTTPS는 통신에서의 인증과 암호화를 위해 넷스케이프 커뮤니케이션즈 코퍼레이션이 개발했으며, 전자 상거래에서 널리 쓰인다. | |
− | + | HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, SSL이나 TLS 프로토콜을 통해 [[세션]]데이터를 암호화한다. 따라서 데이터의 적절한 보호를 보장한다. HTTPS의 기본 TCP/IP 포트는443이다. | |
− | + | 보호의 수준은 [[웹 브라우저]]에서의 구현 정확도와 서버 소프트웨어, 지원하는 암호화 알고리즘에 달려있다. | |
− | + | HTTPS를 사용하는 웹페이지의 [[URL]]은 'http://'대신 'https://'로 시작한다. 웹에서 신용카드를 사용하는 사람들 사이의 흔한 오해 중 하나는, HTTPS를 이용할 때 HTTPS가 “완벽한”보호를 제공해준다고 생각하는 점이다. 그러나 실제로 이것은 웹 서버와 브라우저 간에 전송되는 카드 정보만이 암호화될 뿐이다. 카드 정보는 보통 서버 데이터베이스에 저장되며 (많은 경우 신용카드 처리기에는 전송되지도 않는다), 대개의 정보 유출은 내부 인력에 의해 이루어진다.<ref>islove8587, 〈[http://bitly.kr/uwn74W HTTP란?]〉, 《네이버 블로그》, 2008-03-07</ref> | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | == | ||
− | |||
{{각주}} | {{각주}} | ||
==참고자료== | ==참고자료== | ||
− | * | + | * 공대냥이, 〈[https://helloworld-88.tistory.com/38 IT 용어 정리 - HTTP 란?]〉, 《티스토리》, 2018-10-19 |
* HTTP 위키백과 - https://ko.wikipedia.org/wiki/HTTP | * HTTP 위키백과 - https://ko.wikipedia.org/wiki/HTTP | ||
− | * | + | * 달나라 곰돌이, 〈[https://helloworld-88.tistory.com/38 (기본)HTTP란?]〉, 《헬로우월드》, 2018-07-18 |
− | |||
* HTTP 상태 코드 위키백과 - https://ko.wikipedia.org/wiki/HTTP_상태_코드 | * HTTP 상태 코드 위키백과 - https://ko.wikipedia.org/wiki/HTTP_상태_코드 | ||
* islove8587, 〈[http://bitly.kr/uwn74W HTTP란?]〉, 《네이버 블로그》, 2008-03-07 | * islove8587, 〈[http://bitly.kr/uwn74W HTTP란?]〉, 《네이버 블로그》, 2008-03-07 |