#3 에서 갈라져나온 이슈입니다.

main.scala를 HttpServer.scala, HttpIterates.scala, Request.scala, Response.scala로 분리합니다.

13에 이어서 캐싱(#1)에 기능을 계속해서 구현합니다.

대략 다음과 같이 동작하게 됩니다.

1. 응답을 돌려줄 때, 가능하다면 ETag 헤더를 같이 반환합니다.
2. 클라이언트에 If-Match 헤더가 있다면, 그 값이 *이거나 리소스의 ETag 값과 같은 경우에만 2xx로 리소스를 반환합니다. 이외의 경우에는 304로 응답합니다.
3. 클라이언트에 If-None-Match 헤더가 있다면, 그 값이 *이 아니고 리소스의 ETag 값과 다른 경우에만 2xx로 리소스를 반환합니다. 이외의 경우에는 304로 응답합니다.

현재 Document Root가 항상 실행된 디렉토리로 고정되어있는데, 원하는 디렉토리로 설정할 수 있게 하는 것이 좋겠습니다.

핸들러가 정의되지 않은 리소스에 요청이 들어왔을 때의 기본동작이 구현되어있다면, 웹애플리케이션 만들때의 수고를 다소 덜어줄 수 있지 않을까 생각합니다.

GET /path/to/:container - 컨테이너가 갖고 있는 item들을 xml, json 등의 포맷으로 반환
DELETE /path/to/:container - 컨테이너 삭제
GET /path/to/:container/:id - 리소스 반환
PUT /path/to/:container/:id - 리소스 갱신(없다면 추가)
DELETE /path/to/:container/:id - 리소스 삭제
OPTIONS /* - 해당 리소스에 대해 사용할 수 있는 메소드들을 알려줌.

authentication/authorization을 어떻게 할지가 좀 고민이네요. OAuth를 구현해야하나?

캐싱(#1)에 대한 가장 기본적인 기능 구현으로, Last-Modified와 If-Modified-Since 헤더에 대한 처리를 구현합니다.

1. 응답으로 리소스를 돌려줄 때, 해당 리소스의 갱신일을 Last-Modified 헤더에 담아 보내줍니다.
2. 요청에 If-Modified-Since가 있을 때는, 리소스의 갱신일이 그와 같거나 작다면 304 Not Modified를 반환합니다.

현재 우리의 서버는 요청이 들어올 때 마다 곧이 곧대로 요청한 리소스를 그대로 반환해주고 있습니다.
그러나 같은 리소스를 여러번 요청한 경우에도 매번 다시 보내주는 것은 트래픽 낭비이므로 body 없이 304 Not Modified를 반환해주어야 합니다.

참고자료: RFC 2616 13. Caching in HTTP

• Last-Modified, If-Modified-Since 처리 #13
• ETag #15
• Expires
• Vary

~/mysrc/scala-http$ sbt compile [info] Loading project definition from /home/nori/mysrc/scala-http/project [info] Set current project to la-scala http (in build file:/home/nori/mysrc/scala-http/) [info] Updating {file:/home/nori/mysrc/scala-http/}default-a56465... [info] Resolving org.scala-lang#scala-library;2.10.0 ... [info] Resolving com.typesafe.akka#akka-actor_2.10.0;2.1.0 ... [warn] module not found: com.typesafe.akka#akka-actor_2.10.0;2.1.0 [warn] ==== local: tried [warn] /home/nori/.ivy2/local/com.typesafe.akka/akka-actor_2.10.0/2.1.0/ivys/ivy.xml [warn] ==== Typesafe Repository: tried [warn] http://repo.typesafe.com/typesafe/releases/com/typesafe/akka/akka-actor_2.10.0/2.1.0/akka-actor_2.10.0-2.1.0.pom [warn] ==== public: tried [warn] http://repo1.maven.org/maven2/com/typesafe/akka/akka-actor_2.10.0/2.1.0/akka-actor_2.10.0-2.1.0.pom [warn] :::::::::::::::::::::::::::::::::::::::::::::: [warn] :: UNRESOLVED DEPENDENCIES :: [warn] :::::::::::::::::::::::::::::::::::::::::::::: [warn] :: com.typesafe.akka#akka-actor_2.10.0;2.1.0: not found [warn] :::::::::::::::::::::::::::::::::::::::::::::: [error] {file:/home/nori/mysrc/scala-http/}default-a56465/*:update: sbt.ResolveException: unresolved dependency: com.typesafe.akka#akka-actor_2.10.0;2.1.0: not found [error] Total time: 7 s, completed 2013. 1. 5 오후 8:21:17

보니까 scala 2.10용 akka-actor의 이름이 akka-actor_2.10.0 이 아니라 akka-actor_2.10 이네요. (typesafe 저장소, maven 저장소 둘 다 마찬가지)

아래 링크된 Akka로 HTTP 서버 만들기 예제를 참고하여 Akka를 적용합니다.

http://doc.akka.io/docs/akka/2.0/scala/io.html

클라이언트가 요청해서 서버가 보내주어야 하는 리소스들은, 압축하면 크기가 줄어드는 경우가 많습니다.
jpg, png와 같은 이미지 파일들은 압축을 해도 큰 변화가 없겠지만, html, js, css 와 같은 종류의 파일들은 그 크기가 수분의 일에서 수십분의 일 까지도 줄어들 수 있을 것입니다.
우리 서버는 트래픽을 절약하기 위해 필요한 경우 리소스를 압축해서 보내줄 수 있어야 합니다.

방법은, Content-Encoding 헤더에 인코딩 방법을 적은 뒤 body에 그 인코딩 방법대로 리소스를 압축해서 보내주는 것입니다.

다만 사전에 어떤 인코딩 방법을 사용할지에 대해 서버와 클라이언트가 협상하여 결정할 필요가 있습니다. 이 과정을 "Content Negotiation"이라고 부릅니다.
허용되는 인코딩 방법을 서버가 알려주고 클라이언트가 선택하는 방법을 Client-Driven Negotiation이라고 하며, 반대로 클라이언트가 선호하는 인코딩을 알려주고 서버가 결정하는 방식을 Server-Driven Negotiation이라고 합니다. 또한 이 둘을 혼합하는 방식도 있는데, 그것은 Transparent Negotiation이라고 부릅니다.

참고자료: RFC 2616 3.5 Content Coding, 12. Content Negotiation

TCP 커넥션 한번으로 단 하나의 HTTP 트랜잭션만을 처리하던 최초의 HTTP와는 달리, RFC 2068은 Keep-Alive 헤더를 추가하여 하나의 TCP 커넥션으로 여러 HTTP 트랜잭션을 처리할 수 있는 Persistent Connection을 지원해 주었습니다.

RFC 2616에서는 Keep-Alive 헤더가 정의되어 있지 않으며, Persistent Connection으로 HTTP 트랜잭션을 처리하는 것이 기본이 되었습니다.

참고자료: RFC 2616 8. Connections

기본적으로 body를 갖고 있는 HTTP 메시지는 Content-Length 헤더를 포함해야 하지만, 때때로 HTTP 메시지의 전송을 시작하는 시점에서 body의 길이를 결정하기 어려운 경우가 있습니다.
아주 큰 파일을 전송하거나, 혹은 현재 생성중인 데이터를 보내주어야 하는 상황에 그런 경우에 해당합니다.

해결책은 HTTP body를 여러 덩어리로 쪼개에 보낼 수 있도록 해주는 Chunked Encoding을 사용하는 것입니다. Chunked Encoding을 사용하면 Content-Length 헤더를 보내지 않아도 됩니다.
(그 외에 Persistent Connection을 사용할 수 없는 상황에서 큰 데이터를 전송해야 할 때도 유용할 것입니다)

참고자료: RFC 2616 3.6 Transfer Encoding, 7. Entity

정적 파일을 serving하는 기능을 추가합니다. akka.io의 예제에는 이 기능이 빠져있네요.