구현 | 메소드 실행하기
메소드별 접근방향
내용이 너무 많기 때문에, 각 메소드에 대해 코드는 따로 업로드하지 않습니다. 메소드별로 접근방향을 설명합니다.
GET
일반적으로 리소스의 내용을 읽은 뒤 바디로 놓고 응답을 생성합니다.
취급하는 형식의 리소스인 MIME type을 체크하고, 읽을 때에도 해당 리소스의 MIME type을 확인하여 Content-Type 헤더에 값을 설정해서 돌려보낼 필요가 있습니다.
브라우저 캐싱을 위해 리소스의 Last-Modified 시각을 확인하고 헤더에 추가하여 돌려보내야 합니다.
리소스가 디렉토리인 경우 해당 로케이션의 autoindex 설정 여부에 따라 directory listening을 하거나 index 파일을 찾아서 읽도록 합니다.
리소스가 CGI인 경우는 별도의 장에서 따로 다룹니다.
디렉토리 리스닝에서 실수가 많이 일어납니다. 디렉토리가 여러 깊이에 걸쳐 있는 경우, 하위 디렉토리를 누를 때마다 하위 디렉토리 리스닝이 일어나야 합니다. 그리고 하위 디렉토리의 파일을 누르면 그 파일을 대상으로 GET 요청이 실행되어야 합니다. 폴더와 파일 계층을 깊게 만들어서 꼭 테스트하세요.
HEAD
GET 요청과 같이 취급합니다. 같은 메소드를 실행하도록 하되, 바디가 있더라도 바디를 제외하고 리턴합니다.
바디를 제외한다는 것이 리소스를 읽지 않는다는 것은 아닙니다. HEAD 요청을 보내는 목적 자체가 Content-Length 헤더를 확인해 리소스의 크기를 파악하는 데 있을 수도 있습니다. 정말 GET 요청과 똑같이 처리하고, 응답 메시지를 보낼 때에만 body를 제외하도록 합시다.
POST
body size가 0인 경우 GET 메소드와 다르지 않기 때문에 GET 메소드 실행함수로 리다이렉션해도 상관없습니다.
해당 서브젝트 수준에서는 리소스가 CGI가 아니라면 body가 있든 없든, query가 있든 없든 처리/응답에는 영향이 없습니다.
리소스가 CGI인 경우에는 별도의 장에서 따로 다룹니다.
PUT
URL이 가리키는 위치에 바디로 들어오는 데이터로 파일을 생성하거나 내용을 교체합니다.
새로운 파일이 생성되었느냐, 이미 있는 파일의 내용이 바뀌었느냐에 따라 응답 상태코드가 다릅니다.
일반적으로 생성한 파일의 내용을 바디로 리턴해야 합니다.
DELETE
URL이 가리키는 위치에 있는 리소스를 삭제합니다.
어떤 파일을 삭제했는지에 대한 정보를 응답 바디로 리턴해야 합니다.
원하는 위치에 원하는 리소스를 마음대로 생성, 변경, 제거하기 때문에 매우 위험합니다. 서버 내의 자원에 영향을 미치는 메소드들을 unsafety method라고 하는데, 그 중에서도 PUT이나 DELETE는 보안상 위험해서 서버에서 허용하는 경우가 잘 없습니다. POST를 통해 cgi 프로그램의 제어를 거치고 안전하게 처리하는 것이 선호됩니다.
TRACE
리퀘스트 메시지를 그대로 리턴해야 합니다. 즉, 리퀘스트를 읽는 과정에서 원본 메시지를 그대로 저장해놓는 변수가 하나 필요합니다. 리퀘스트의 바디가 클 수 있기 때문에 메소드가 TRACE일 때에만 저장하는 것도 방법입니다.
리퀘스트 메시지를 그대로 리턴한다는 것은 응답 메시지의 body로서 리퀘스트 메시지를 보낸다는 것이지, 정말 그대로 보낸다는 뜻은 아닙니다. 응답 시작줄, 헤더는 다른 응답과 같이 필요합니다. TRACE 메소드 실행 함수에서는 이런 작업들을 처리합니다.
OPTIONS
OPTIONS 메소드는 URL이 루트 디렉토리일 경우 서버가 취급하는 메소드 전체를, 특정 리소스를 지목하여 요청이 올 경우에는 해당 리소스에 해당하는 로케이션에서 허용하는 메소드들의 목록을 Allow 헤더의 값으로 설정하여 리턴합니다.
헤더의 값은 복수가 올 수 있습니다. 크롬의 개발자 도구에서 네트워크 창을 열어서 value가 여러 개일 경우 어떻게 표시되는지 확인해보세요. 그리고 header에 관한 자료구조를 어떻게 처리할 것인지 신중히 고민해보세요. string:string vector map, string:string map, stirng:string multimap 모두 장단점이 있습니다.
Last updated