FEAT-auto-index-uri #125
Description
Description
Get auto_index 기능을 구현하는 과정에서 location에 대해서는 구현하는 것이 어렵지 않았음. 그러나 서버 전체 location에 대해서 auto index 를 사용해야 하는 경우 convert url 의 기능이 정상적이지 못함. 따라서 이를 위한 auto index 기능 정의 및 이를 위한 request 로직을 구성해야함.
Auto Index 기능에 대한 로직
request
- request 에서 최초 접속 시 서버 자체의 설정에서 auto index 기능 플래그를 확인한다.
- auto index가 활성화 된 것을 알게 되면, /만 들어오는 경우는 무조건 서버의 ROOT 를 확인하고 치환한다. 이때 치환의 구조는 다음과 같이로 고정한다.
./+server ROOT/ - 그 외에 모든 로케이션이 들어오는 경우, 해당 로케이션은 무조건 convert 를 하지 않고 전달한다.
-
location에서도 마찬가지로 확인이 되어야 하는데, auto index 플래그가 확인이 되면, /location 만을 동일한 구조로 수정하며 나머지는 바꾸지 않는다. - 특정 location의 auto index는 들어오는 메시지를 정상적으로 파싱을 하고, origin uri 와 location 설정만 잘 해주면 된다.
Get AutoIndex Method
- 서버 전체가 켜진 경우, 처음부터 확인이 되므로,
./ROOT directory/specific directory/file의 구조를 띄어야함. 축약형으로 하거나 location의 추상적 URI 구조를 하면 해석이 혼란스러움 -
.현재 위치를 나타내는 해당 경로는 탐색이 된 경우 삭제한다. (페이지에서 보여주지 않는다) - 현재 위치가 서버 기준 ROOT 인 경우
..은 표시하지 않으며, 이전 경로로 접근할 수 없도록 한다. 그러나 그 다음 깊이의 경로의 경우 이를 출력해 줘야 한다. -
그 외의 디렉토리들은 HTML 문서를 제작할 때, 반드시 현재 지정된 로케이션을 기준으로./으로 만든 뒤 그 뒤에 디렉토리를 집어 넣는 방식으로 한다. 즉, 서버의/를 기준으로 설명되도록 한다. - 위치를 파악하는 것은 chdir 을 통해 현재 위치를 판단한다. 더불어 서버 전체에 autoindex가 켜져 있는 경우와 로케이션인 경우를 부득이 잘라서 디렉토리 구조를 만들어 줘야 하지 않나 고려된다. (이유 : 로케이션의 경우 해당 로케이션에서 벗어나게 되면 별개일 뿐만 아니라, 해당 로케이션에서 다음 디렉토리까지 가야 한다고 한다면 location을 계속 확인할 수 있어야 한다.)
- 서버 전체가 autoindex인 경우
- / 가 들어오는 경우는 무조건 번역 될 것이며, 이후 들어오는 모든 URL의 converting은 없으므로, 현재 파일 이름을 받아와서 들어오는 디렉토리 경로에 그대로 붙여서 작업하면 된다. (예시 / -> ./storage/static/file_name 이거나 ./storage/static/asset -> ./storage/static/asset/src.png)
- 로케이션이 auto index인 경우
- 이 경우 추가 depth를 위해 converting이 되는 로직을 살려야 한다. 따라서 컨버팅 될 것을 고려하여 로케이션 + 파일 명으로 구조를 짜야 한다.
- 예시 ) /location -> request 파트에서 converting이 되어 들어옴, 따라서 해당 위치를 연 뒤, 파일 이름을 출력할 땐 다음처럼 진행한다. /location/file-name.html 또는 /location/src/.
- /location/src 와 같은 경우를 누르게 된다면, converting이 되어 들어오게 될 것이다. 그러나 그런 세팅과정을 통해 들어왔다고 하더라도 실제 파일 경로는 다음처럼 출력 되어야 할 것이다. /location/src/file-name or /location/src/aseet : 이렇게 들어와야 하는 이유는 컨버팅 되는 로직을 그대로 살리는 역할을 하며, location_config_ptr을 특정하기 위해서 이며, depth가 늘어나도, 그 늘어나는 depth 를 적절히 처리하기 편리하려면, 해당 location 이후에는 절대경로로 가는게 낫기 때문이다.
- 서버 전체가 autoindex인 경우
- 보다 적절한 파일 구조 및 파일 작업을 위해, 우선 작성해야 하는 모든 URI를 변환하여 정리하는 경로 구조체가 필요하다. 이때, 해당 객체가 파일인지, 디렉토리인지를 구분하기 위한 플래그를 저장해둔다(경로전체를 합친 map key, 파일 명으로 value 를 해도 좋을듯). 필요하다면 기준이 되는 경로 등을 보관해야함.
ETC
- 왜 Map으로 경로와 파일 명을 기록하고 이를 재 출력해야 하는가? : 그냥 순간적으로 데이터를 출력하는 방식으로 할 경우 내부 VNODE 구조에 따라 dirent 구조체에서 랜덤하게 파일과 디렉토리가 섞여서 나옴. 따라서 디렉토리를 담아두는 경우와, 파일을 담는 경우를 구분하고, 동시에 내부에서 경로 전체값(key)을 통해 정렬이 되면 훨씬 보기 좋을 것이기에 해당 방식으로 정리. 이후 반복자를 통해 호출하면 보다 깔끔한 로직을 확보할 수 있어 보인다.
- 왜 request에서 해당 플래그를 읽어서 작동해야 하는가? : Get에서 이를 적절히 처리하는 방식으로 하려 했으나, 추상화의 경우와 로케이션들이 꼬이는 것들 등등... request 파트에서 converted 되는 과정에서 신뢰할 수 없는 URL이 전달되고, 이때 꼬이게 됨. 더불어 해당 location을 넘어가는 루트에 진입하는 경우등을 고려하면 request에서 먼저 검증 작업이 들어가야 함.