Вышел wZD 1.0.0 - сервер хранения и выдачи файлов

а что такое мОнда? все уже, можешь не релизить. в зеде тебе не переплюнуть.

ага, теперь более-менее понятно. спасибо, что поделился.

Вы не сильно придирайтесь

не подумайте, я не придираюсь. просто занимаюсь этим, вот и спрашиваю, пока не забанили. ;)

Я понял, что у вас проблема кучи маленьких файлов, для которых буферизация нжинксом ничто и даже ускоряет, поэтому вы ни чанками ни вообще этим вопросом и не занимались. А у меня задача, сделать замену хотя бы ftp на webdav за nginx-ом и я даже в потенциале не вижу ее решения.

Хотя в реальной жизни обычно делают так - для GET запросов снаружи ставят реверс прокси, а заливают большие файлы напрямую

В реальной жизни при достижении предела размера тела http-запроса файл просто молча никуда не сохраняется. Или пишут свой веб-интерфейс и в браузере на джаваскрипте организуют загрузку чанками.

Ничего другого я еще не видел.

Завез я уже поддержку HTTPS, Keepalive, авторизацию per vhost, включение отключение 404-ых, метод POST(только бинарные данные так же как и в PUT), метод OPTIONS, и еще по мелочи. Пока только в ветке мастер, если кому надо можете попробовать собрать потестировать.

AVL2. Если проблема именно с буферизацией, то можно работать с wZD напрямую - у меня нет буферизации никакой, все через мелкие буферы на лету - большие файлы запросто без пожирания оперативки - хоть писать, хоть читать, теперь считайте есть все что надо по минимуму чтобы работать без Nginx.

Я могу сделать еще включение Transfer-Encoding: Chunked на стороне своего сервера и вывести это в опцию на виртуальный хост. То есть или Content-Length точный использовать можно, или Chunked - если это чем-то поможет я могу сделать, это совсем недолго сделать. Я же просто не знаю кому что надо на текущий момент.

Есть всего 2 варианта на стороне сервера - или Chunked или Content-Length, только какой-то 1 из них можно включить на виртуальный хост. Ниже пример с Content-Length, все скачалось, ничего не потребляло в оперативке на стороне сервера, у меня столько памяти-то нет.

Файл размером 64GB я совершенно нормально залил и скачал curl, без каких-то временных файлов на стороне сервера, только таймауты на стороне сервера увеличил readtimeout и writetimeout до 600 сек. Единственно что таймауты не работают нормально в версии 1.0.0, только в master ветке это пока реализовано.

GET /BIG.null HTTP/1.1
Host: localhost:9799
User-Agent: curl/7.52.1
Accept: */*

{ [5 bytes data]
 HTTP/1.1 200 OK
 Accept-Ranges: bytes
 Access-Control-Allow-Origin: *
 Cache-Control: max-age=0
 Content-Length: 68719476736
 Content-Type: application/octet-stream
 Etag: 5e28be09-1000000000
 Last-Modified: Thu, 23 Jan 2020 00:26:33 GMT
 Date: Wed, 22 Jan 2020 21:46:52 GMT

{ [901 bytes data]
 99 64.0G   99 63.4G    0     0   350M      0  0:03:06  0:03:05  0:00:01  385M* Curl_http_done: called premature == 0
100 64.0G  100 64.0G    0     0   352M      0  0:03:06  0:03:06 --:--:--  439M
* Connection #0 to host localhost left intact

В дополнение, в моем сервере вообще нет ограничения на max_body_size, потому что оно мне просто не нужно, нет временных файлов, не поедается память, считайте что это работает потоком. Только таймауты надо увеличить и всё, в том числе на стороне клиента если там имеется таймаут на общее время передачи данных. В релизе 1.1.0 следующем - таймауты будут работать.

Transfer-Encoding: Chunked - нужен если только для совместимости с какими-то древними серверами или клиентами, то есть режим передачи не влияет, клиенту наоборот лучше знать общий Content-Length, чтобы докачка работала при обрыве связи.