никто, потому что он умрет ?

а вы оба вернетесь на галеры

ладно, шутка

99.9% стартапов умирают

100% людей умирают

поэтому надо делать работу так, чтобы начальнику было страшно тебя потерять ? это дает возможность провести время жизни с удовольствием

т.е. говнокодить

единственный правильный путь в данном случае - определить пределы применимости возможных решений, и не предполагать, что все будет хорошо, а проверить

Какая-то софистодемагогия

т.е. говнокодить

+1 :)

"страшно потерять". наоборот не должно быть страшно

необязательно же втыкать на аутсорсе на проходных проектах

бас-фактор 1 - это отстой

Да вы тут все пяные

Адель, bus-factor - это проблема менеджера

если разработчик пишет хорошо, а руководство не может это оценить - это проблема выбора разработчика

если руководству нет дела до будущего проекта - это вопрос выбора, хочу ли я заниматься таким проектом?

обычно я отказываюсь

и это не софистика

Адель, bus-factor - это проблема менеджера

А если нет менеджера - то и проблемы нет.

а если менеджера нет - то ты сам становишься менеджером

Только убивший менеджера может стать менеджером

ну типа того, да

я считаю что менеджер должен укусить человека, чтобы тот стал менеджером

если ты уволил менеджера, и проект продолжает работать - ты очень хороший менеджер )))

помоему они так появляются

если ты уволил менеджера, и проект продолжает работать - ты очень хороший менеджер )))

Либо очень бесполезный менеджер

Адель, менеджер - это роль, это задачи, которые кому-то надо выполнять

кто-то должен оформлять документы

Чтобы написать запрос выборки статей с комментариями - тут надо консилиум минимум из трех менеджеров собирать

оформлять документы, ставить задачу.

Обсуждать приоритеты и требования. Доказывать нужность проекта.

ну смотри, при выборке статей с комментами 3 базовых решения на SQL в рамках одного сервера, и еще множество решений при шардинге и внешних запросах

Он так никогда не сможет выбрать что же ему делать

ему нужно понимать что он хочет сделать

а кто-нибудь когда-то делает защиту механизма upload-а файлов от неавторизованных запросов? например, что upload делает зареганный пользователь, а не кто угодно

угу

а как?

и даже RateLimiter

а расскажи!

а чем аплоад-файл запрос отличается от обычного? :)

php ж получает управление, когда файл уже на сервере целиком

ааа

кароч.. я картинки гружу base64 :)) пост-запросом :)

это немного упрощает

ты на JS конвертируешь бинарный файл в base64?

картинку

ты еще не знаешь, картинка это или нет

я знаю что картинка :)

откуда?

потмоу что там может быть только картинка :))

по логике

что помешает мне отослать тебе отфонарный POST body?

так я на клиенте файл в картинку гружу

и потом резать даю эту кратинку

ну т.е. я тебе не помощник

я бы не стал советовать так делать со всеми файлами

то есть, у тебя лимит на размер файла картинки ограничен 8Мб после конвертации в base64

да. там мелочь. нам надо 400 на 400 картинки

то есть, где-то до 6 метров ... для фотки должно хватать

они там больше 100Кб не бывают

ну и соответствнно, у тебя не multipart

ессно

чтобы вычитать через ://input

я думаю твоя задача решается как-то хитро через скриптинг нгинкса

ERROR: S client not available

ну да, авторизация через подзапрос с пробросом куки

выходит как-то так

мне нужна тоже картинка, но POST в base64 проблему левых неавторризованных запросов не решает

secure_link можно посмотреть

а че это такое?

http://nginx.org/ru/docs/http/ngx_http_secure_link_module.html

разрешить толстый аплоад только для локейшена с проверкой валидности ссылки

любопытно, кушает ли оно POST - но почему бы и нет

тут скорее любопытно, в какой момент проверка - после приема заголовков или всего тела

да, да

я когда стал в этом копаться, осознал, что это неслабая дырка во всех сайтах upload-ом на php

я бы не назвал это дырой... максимум способ доса, но в общем таких способов хватает и так

Я так раньше бекдоры в картинке заливал на сайты ?

И вуаля доступ есть.))

Чисто ради каайфаа

http://nginx.org/en/docs/http/ngx_http_auth_request_module.html

ну, не дыра, а способ положить сайт гораздо проще, чем забиванием канала или cpu

да, через подзапрос, получается

что сделает nginx, если ему отправить тысячу запросов POST с большим body? по 100 мегабайт, например - будет писать их на диск?

не проще - файл еще передать нужно, это время... проще по скриптам подосить... и максимум что ты сделаешь - это забъешь раздел client_body_temp

этот раздел обычно совпадает с основным разделом, или, если все очень хорошо - с разделом для хранения файлов

время - а кто его ограничивает?

у многих ли 100 гиг свободных на севере? если винт забить - сервер сдохнет

можно поиграть локально ? сделать кучу одновременных запросов к localhost и посмотреть на диск

сложно спрогнозировать, ты не забывай, что после окончания запроса файл удаляется... и передается не мгновенно, т.е. растет от 0 до максимального поста со скоростью аплоада

так 1000 соединений - это не много

вопрос не в соединениях, вопрос в канале уже скорее ;)

медленно передавать тысячу файлов одновременно

без авторизации, файлы удалятся, конечно, но сначала они загрузятся и запишутся

пока они будут загружаться - они будут на диске

а если это системный диск - давай, до свидания

надо поиграть ?