사실 서버가 보내준 것은 리소스가 아니다. 다음과 같은 HTTP GET 요청을 서버에 보내서 GET https://example.org/greeting Host: example.org Accept: text/plain, text/html; q=0.9 *; q=0.1 Accept-Language: en, ko; q=0.9, *; q=0.1 "hello"라는 메시지를 응답으로 받았다고 해 보자. HTTP/1.1 200 OK Content-Length: 6 Date: Sun, 19 Mar 2017 10:20:47 GMT Last-Modified: Sun, 19 Mar 2017 08:00:00 GMT Content-Type: text/plain Content-Language: … REST의 representation이란 무엇인가 계속 읽기
[카테고리:] HTTP
바쁜 개발자들을 위한 REST 논문 요약
REST란 무엇인가? REST는 Representational State Transfer의 줄임말로, 웹을 위한 네트워크 기반 아키텍처 스타일이다. REST는 Roy T. Fielding이 그의 박사학위 논문 "Architectural Styles and the Design of Network-based Software Architectures" 에서 처음 소개하였다. 그의 논문을 읽고 매우 간략히 요약해보았다. 논문의 모든 부분을 동등하게 요약하지는 않았고, REST가 무엇인가를 이해하는데 초점을 맞추어 차별적으로 요약하였다. 논문 요약 1장: Software … 바쁜 개발자들을 위한 REST 논문 요약 계속 읽기
웹 프로그래머를 위한 HTTP 완벽 가이드 읽는 법
HTTP 완벽가이드는 이름 그대로 HTTP를 매우 자세히 다루고 있는 책이다. HTTP를 이해해야 하는 사람은 웹 프로그래머만은 아니므로, 이 책은 웹 프로그래머만을 위해 쓰여진 책이 아니다. 따라서 웹 프로그래머가 이 책의 내용을 모두 다 완전히 이해해야 하는 것은 아니며, 중요도가 장 마다 크게 다르다. 웹 프로그래머의 시간은 유한한데 반해 공부해야 할 내용은 어마어마하게 많으므로, 중요한 것만 … 웹 프로그래머를 위한 HTTP 완벽 가이드 읽는 법 계속 읽기
400 Bad Request와 403 Forbidden의 의미에 대해
HTTP/1.1 HTTP/1.1을 정의한 최신 명세인 RFC 2616에 따르면, 흔히 알고 있는 것과는 달리 의외로 403 Forbidden은 권한(authorization)에 대한 에러가 아니다. 그냥 요청은 이해하지만 수행을 거절(refuse)하겠다는 의미이다. 그리고 또 의외로 400 Bad Request는 그냥 "요청이 잘못되었다"라는 의미가 아니라 "요청의 syntax가 잘못되어서 이해를 못하겠다"라는 의미를 담은 응답이다. 400 Bad Request에 대한 설명 (( http://tools.ietf.org/html/rfc2616#section-10.4.1 )) The request … 400 Bad Request와 403 Forbidden의 의미에 대해 계속 읽기
절대경로가 "//"로 시작하는 URL은 스펙 위반일까?
http://example.org//foo/bar 와 같이 path의 절대경로가 //로 시작하는 것은, URI의 정의에 대한 최신 명세인 RFC 3986을 위반한 것이다. 절대 경로는 "//"로 시작해서는 안된다. path-absolute ; begins with "/" but not "//" 그러나 HTML에서 <a href="//foo/bar">test</a> 와 같은 상대경로를 사용하는 것은 아무 문제가 없는데, 왜냐하면 HTML의 가장 최신 표준인 4.01(아직 5는 드래프트)은 RFC 3986보다 훨씬 오래된 RFC … 절대경로가 "//"로 시작하는 URL은 스펙 위반일까? 계속 읽기
HTTP/1.1의 Range 요청과 이를 활용한 Pagination
HTTP/1.1은 Range 요청을 지원한다. 클라이언트가 Range 헤더를 통해 어떤 리소스의 일부분만을 요청하면, 서버는 그 부분만을 반환하는 방식으로 동작한다. /file.zip를 100바이트에서 200바이트까지만 가져오는 클라이언트의 요청과 그에 대한 서버의 응답은 다음과 같다. 요청 GET /file.zip HTTP/1.1 Range: bytes=100-200 ... 응답 HTTP/1.1 206 Partial Content Content-Range: bytes 100-200/500 ... 위의 예에서 단위는 'bytes'를 사용했다. 사실 HTTP/1.1을 정의한 RFC … HTTP/1.1의 Range 요청과 이를 활용한 Pagination 계속 읽기
iOS6 사파리의 POST 캐싱 버그에 대해
iOS6의 사파리는, 기본적으로 POST 요청에 대한 응답을 캐싱한다. 여기서 치명적인 문제가 발생한다. 서버에서 요청의 대상이 되는 리소스가 갱신되었음에도 불구하고, 사파리는 캐시했던 이전 응답을 사용자에게 보여주게 될 수 있다. 문제가 발생하는지에 대한 테스트는 여기에서 해볼 수 있다. 이 테스트에서 브라우저는 두 번의 POST 요청을 서버에게 보내고 서버는 그 요청에 대해 각각 다른 응답을 한다. 그러나 iOS6의 … iOS6 사파리의 POST 캐싱 버그에 대해 계속 읽기
웹서비스에 한글 아이디를 허용하게 되면 난감해지는 HTTP적인 이유
그건 Basic Authentication 때문이다. 웹서비스에 한글 아이디를 허용하면 Basic Authentication을 적용하기 어려워진다. 뭐가 문제인가 HTTP의 Basic Authentication은 매우 단순한 인증 체계이다. 클라이언트가 사용자의 아이디와 비밀번호를 "아이디:비밀번호" 꼴로 만들어 base64 인코딩하여 전송하면, 서버가 확인 후 틀렸으면 401 Unauthorized를 돌려주고 맞았으면 요청을 적절히 처리한다. 보통 웹브라우저로 사이트에 들어가는데 팝업이 짠 뜨면서 로그인을 요구하면 대개 이 Basic Authentication이라고 … 웹서비스에 한글 아이디를 허용하게 되면 난감해지는 HTTP적인 이유 계속 읽기
"HTTP/1.1 200" 은 틀리고 "HTTP/1.1 200 " 은 맞는 이유
HTTP 응답은 항상 다음과 같은 Status-Line 으로 시작한다. HTTP/1.1 200 OK 왼쪽부터 순서대로 HTTP-Version, Status-Code, Reason-Phrase가 온다. 그런데 만약 응답을 해줘야 하는 HTTP 서버가, 적절한 이유구문을 결정하지 못해 Reason-Phrase 없이 응답을 보내려면 어떻게 해야 할까? 그냥 "HTTP/1.1 200" 로 보내면 될 것 같지만, 정답은 "HTTP/1.1 200 "이다. 끝에 공백문자를 하나 넣어줘야 한다. 이유가 뭘까? RFC … "HTTP/1.1 200" 은 틀리고 "HTTP/1.1 200 " 은 맞는 이유 계속 읽기
HTTP status code 실험
요즘 회사에서 HTTP 스터디중이다. HTTP/1.1의 다양한 Status Code들에 대해 공부한 뒤, 실제 웹브라우저가 Status Code에 대해 어떻게 대응하는지 궁금해졌다. 그래서 구글 크롬을 가지고서 테스트 해 보았다. 일단 status code를 원하는대로 만들어서 응답해주는 코드를 간단히 작성했다. header("HTTP/1.1 ".$_REQUEST['status']." ".$_REQUEST['reason']); if (isset($_REQUEST['body'])) { echo $_REQUEST['body']; } 예를 들어 http://npcode.com/test/http-resonse.php?status=201 이렇게 요청하면 201로 응답해준다. 이걸로 구글크롬을 테스트 해 … HTTP status code 실험 계속 읽기
eungjun 