memo.text

HTTP Header X-Script-Name을 이용해 SCRIPT_NAME을 설정
HTTP Header X-Scheme을 이용해 원래 요청이 http인지 https인지 알아낸다 (로컬에서는 굳이 https를 쓸 필요가 없으므로 nginx에서 https를 사용 후 애플리케이션 쪽으로 http를 이용해 reverse proxying 한다 이 때 원래 요청이 https인지 http인지 알기 위해 X-Scheme)
HTTP Header X-Forwarded-For을 이용해 클라이언트의 원래 ip를 알아낸다

http://flask.pocoo.org/snippets/35/
Flask의 경우 위와 같은 방법을 이용해 https://example.com/myprefix/myapp -> http://192.168.0.1:5001/myapp 로 reverse proxying을 할 수 있다
이 때 X-Script-Name: /myprefix이다

Django 는 하나의 project 안에 여러 개의 app을 가지고 있다
url routing을 담당하는 urls.py는 project, app마다 존재한다
project1
-urls.py
-app1
--urls.py
-app2
--urls.py

아마 X-Script-Name: /project1과 함께 /project1/app1 으로 request를 보내면
먼저 여러 프로젝트 중에 project1을 선택하고 project1의 urls.py에서 X_SCRIPT_NAME을 /project1/app1으로 바꾼 뒤 app1으로 routing 하지 않을까 하는 것이 나의 추측이다

Flask는 project단위가 아니라 app단위지만 Werkzeug 를 이용하여 여러개의 app을 라우팅한다.


일단은 바람직하지는 않지만 하나의 앱만 있다고 가정하고 프로그래밍하자


["wsgi.input"].read()가 꼭 진짜 소켓의 read일 필요가 없다
단순히 호출했을 때 데이터만 돌려주는 함수이면 충분하다


post data를 처리하는 방법은 꽤나 골치아프다 특히 어떻게 하면 wsgi.input과 같은 인터페이스에 데이터를 넘길지가 문제이다


wsgi.input 은 blocking io이다 이는 Content-Length를 실제 데이터보다 크게 표시할 경우 서버자체가 완전히 블로킹 되는 문제가 있다


flask 자체 서버도 무한히 블로킹 되었고 wsgiref 서버도 마찬가지였다
멀티프로세스 서버인 gunicorn과 uwsgi는 타임아웃을 두었지만 여전히 서버의 성능에 치명적이었다

https://stackoverflow.com/questions/2176443/is-a-return-value-of-0-from-write2-in-c-an-error/2176748#2176748
http://stackoverflow.com/questions/3989811/eagain-error-using-berkeley-socket-api

socket 에 file을 쓸 경우 sendfile()을 사용하는 것이 훨씬 더 효율적