ETag, If-Match, If-None-Match 헤더에 대한 처리 about scala-http HOT 11 CLOSED

서버가 ETag 계산을 매번 하게 될 것 같은데, 좀 확인해봐야겠네요.

from scala-http.

음... 실제로 매번 하게 되네요. 지금은 sha1을 계산하는 방식이라 별로 빠르지 않을텐데...

sha1sum 프로그램으로 해보니 1메가짜리 파일은 0.02초, 1기가짜리 파일은 4.46초 걸리네요.

from scala-http.

ETag의 정확도를 어느 수준까지 가져갈것이냐의 문제인것 같습니다.

현재 코드를 보면, 전체 파일의 내용을 기준으로 해싱처리를 하게되면, 1bit라도 틀린 파일은 정확히 잡을 수는 있겠지만, 시간이 오래 걸립니다.

웹 캐싱시에는 정확도는 다소 낮더라도, 파일의 특정 속성을 조합하여서, 해싱 처리해도 충분할 것 같습니다.
예를 들어서 '파일의 풀패스', '마지막수정시간 유닉스 타임스탬프', '파일의 길이'를 이어 붙인 문자열을 해싱처리하여도, 충분히 변경된 파일을 발견할 수 있을 것 같네요.

해싱된 ETag 값을 캐싱하는 방법도 있겠지만, 이 경우에는 파일 시스템을 모니터링하고 있어야 겠네요.

from scala-http.

@miracle0k 그렇게 하면 1초 동안 두 번 변경된 파일의 변경전/변경후 ETag가 같아지는 문제가 있을 것 같네요.

from scala-http.

@npcode JVM에서는 밀리세컨드로 출력되지 않나요? 확인해 봐야할 것 같네요.

from scala-http.

@miracle0k 좀 찾아보니까 운영체제 및 파일시스템에 따라 timestamp의 정밀도가 달라지네요. fat는 2초라고 하고, linux 2.5.48 이상 + ext4라면 1ns라고 하는군요.

sha1과 timestamp 모두 지원하고 사용자가 선택할 수 있게 하는 것이 좋을 것 같아요.

from scala-http.

@npcode 웬지 파일 시스템마다 다른점이 있을거라고 생각은 했었는데, 정말로 그렇군요.
그래서 기존의 웹서버들이 어떻게 etag 만드는지 찾아봤습니다.

• apache 1.3 * 2.x : inode-size-timestamp
• IIS 5.0 & 6.0 : Filetimestamp:ChangeNumber

그리고 위의 방식을 이용하면 서버마다 etag가 다르게 생성되어서, 로드벨런스 붙여서 부하분산했을때는 같은 파일이라도 캐쉬가 되지 않는다네요.

그래서 etag는 기본적으로 꺼두기를 권장하네요.. ^^

따라서 위의 의견대로 etag 생성 전략을 선택할 수 있게 하는게 좋을것 같습니다... ^~^

from scala-http.

조금 더 살펴보았는데 jvm에서 1ns 정밀도로 mtime을 얻는 것은 간단하지 않네요. native 라이브러리를 작성해서 JNI로 갖다써야 할 것 같아요.

도전해보면 나름 재미는 있을듯?

from scala-http.

java8에서는 1ns 정밀도가 가능한 모양이에요. http://bugs.sun.com/view_bug.do?bug_id=6939260

from scala-http.

java8도 1ns까진 아니고 1마이크로초 정밀도네요.

from scala-http.

java에서 현재 1ms 정밀도로 최근변경시각을 얻을 수 있지만, 윈도(NTFS)에서만 되고 다른데선 1s인 것 같네요. 그렇다면 굳이 timestamp로 ETag를 주는 건 의미가 없을 것 같아요.

제가 sunjdk를 안 쓰고 openjdk를 써서 그런건지는 잘 모르겠네요.

from scala-http.