Здравствуйте, Ziaw, Вы писали:
I>>Например HTTP POST download.
Z>Это что?
Это download через POST реквест. Очень популярная вещь, вообще говоря. Отправляешь html,xml,json, а получаешь например pdf. Или, например, стейтлесс эндпоинт, куда ты отправляешь много данных в реквесте, и получаешь много данных в респонсе.
Здравствуйте, Ikemefula, Вы писали:
I>Это download через POST реквест. Очень популярная вещь, вообще говоря. Отправляешь html,xml,json, а получаешь например pdf.
Зачем встраивать его в pipelining?
I>Или, например, стейтлесс эндпоинт, куда ты отправляешь много данных в реквесте, и получаешь много данных в респонсе.
POST в HTTP/REST используется для statefull операций, поэтому пайплайнинг для него отключили. Чисто из спортивного интереса мне захотелось узнать, в каком месте это может стать проблемой. Была гипотеза, что "HTTP POST download" это какой-то неизвестный мне термин, но после объяснения стало еще менее понятно.
Здравствуйте, Ziaw, Вы писали:
I>>Это download через POST реквест. Очень популярная вещь, вообще говоря. Отправляешь html,xml,json, а получаешь например pdf.
Z>Зачем встраивать его в pipelining?
Для больших pdf возможно и не нужно, но вот json — нужно, и вообще для мелочевки очень желательно.
I>>Или, например, стейтлесс эндпоинт, куда ты отправляешь много данных в реквесте, и получаешь много данных в респонсе.
Z>POST в HTTP/REST используется для statefull операций, поэтому пайплайнинг для него отключили. Чисто из спортивного интереса мне захотелось узнать, в каком месте это может стать проблемой. Была гипотеза, что "HTTP POST download" это какой-то неизвестный мне термин, но после объяснения стало еще менее понятно.
Тебе непонятно, что download реализуют не только через Get, но и Post ?
Предложи стейтлесс вариант АПИ для конверсии вида формат1 -> препроцессор -> формат2 -> постпроцессор
Здравствуйте, Ikemefula, Вы писали:
I>Для больших pdf возможно и не нужно, но вот json — нужно, и вообще для мелочевки очень желательно.
Есть соглашение, что POST не идемпотентен, пайплайнить такие операции чревато неприятными сюрпризами для разработчика бэкенда. Если пайплайнинг желателен — можно использовать PUT. Но обычно для мелочевки крайне желательно объединять ее в один запрос. Независимо от наличия пайплайнинга по ресурсам это будет намного менее затратно.
I>Тебе непонятно, что download реализуют не только через Get, но и Post ?
Мне непонятно, зачем применять слово download не по назначению. И непонятно, почему потребовался именно POST.
I>Предложи стейтлесс вариант АПИ для конверсии вида формат1 -> препроцессор -> формат2 -> постпроцессор
Конверсия операция идемпотентная, для таких операций в HTTP есть PUT. Это дает возможность софту понимать, что результат запроса можно смело закешировать и не дергать сервер лишний раз.
Здравствуйте, Ziaw, Вы писали:
I>>Для больших pdf возможно и не нужно, но вот json — нужно, и вообще для мелочевки очень желательно.
Z>Есть соглашение, что POST не идемпотентен, пайплайнить такие операции чревато неприятными сюрпризами для разработчика бэкенда. Если пайплайнинг желателен — можно использовать PUT. Но обычно для мелочевки крайне желательно объединять ее в один запрос. Независимо от наличия пайплайнинга по ресурсам это будет намного менее затратно.
Я не сильно глубоко знаю про http, какие именно сюрпризы надо ждать ?
I>>Тебе непонятно, что download реализуют не только через Get, но и Post ? Z>Мне непонятно, зачем применять слово download не по назначению. И непонятно, почему потребовался именно POST.
Это устоявшаяся практика. Не я её изобрёл.
I>>Предложи стейтлесс вариант АПИ для конверсии вида формат1 -> препроцессор -> формат2 -> постпроцессор
Z>Конверсия операция идемпотентная, для таких операций в HTTP есть PUT. Это дает возможность софту понимать, что результат запроса можно смело закешировать и не дергать сервер лишний раз.
А вот и не верно. Поднастроил ты конвертор в админке, отправляешь тот же файл второй раз с теми же хидерами. Какой результат ждать ?
Здравствуйте, CreatorCray, Вы писали:
N>>Ты не согласен с MSDN? Тогда покажи, где и почему они врут. CC>Потому что функционал этот доступен (официально) с XP, а по факту как бы не с W2k
Я пользовался этим \\?\ в четвертой NT, и это уже было описано в MSDN.
Здравствуйте, Ziaw, Вы писали:
I>>Для больших pdf возможно и не нужно, но вот json — нужно, и вообще для мелочевки очень желательно.
Z>Есть соглашение, что POST не идемпотентен, пайплайнить такие операции чревато неприятными сюрпризами для разработчика бэкенда. Если пайплайнинг желателен — можно использовать PUT.
Для идемпотентности можно использовать uuid в запросе (самый простой, но вполне рабочий метод).
PUT честно пойдёт только если заранее знаешь/задаёшь постоянный id ресурса и сервер тебе доверяет в этом. Что в общем случае ой не.
А для POST этот id можно делать временным и специфичным для конкретного клиента (авторизационного токена или что там вместо него на этой неделе).
I>>Тебе непонятно, что download реализуют не только через Get, но и Post ? Z>Мне непонятно, зачем применять слово download не по назначению. И непонятно, почему потребовался именно POST.
GET в принципе не допускает тело запроса. Поэтому если параметров URL не хватает, приходится извращаться.
I>>Предложи стейтлесс вариант АПИ для конверсии вида формат1 -> препроцессор -> формат2 -> постпроцессор
Z>Конверсия операция идемпотентная, для таких операций в HTTP есть PUT. Это дает возможность софту понимать, что результат запроса можно смело закешировать и не дергать сервер лишний раз.
PUT в этом смысле важен только для промежуточных прокси, а не для того сервера, что делает реализацию. Последний может проверить и другими методами.
Здравствуйте, netch80, Вы писали:
N>Для идемпотентности можно использовать uuid в запросе (самый простой, но вполне рабочий метод).
Можно конечно. Но ранее была гарантия, что запросы POST будут выстроены в очередь, то, что ее оставили — имхо, верно.
N>PUT честно пойдёт только если заранее знаешь/задаёшь постоянный id ресурса и сервер тебе доверяет в этом. Что в общем случае ой не. N>А для POST этот id можно делать временным и специфичным для конкретного клиента (авторизационного токена или что там вместо него на этой неделе). N>GET в принципе не допускает тело запроса. Поэтому если параметров URL не хватает, приходится извращаться.
Ни PUT ни POST сами по себе не требуют id ресурса. Если нужно тело запроса и pipelining — используем PUT, если нет выбираем в зависимости от других факторов.
N>PUT в этом смысле важен только для промежуточных прокси, а не для того сервера, что делает реализацию. Последний может проверить и другими методами.
Мы подбираем метод подходящий под задачу. То, что промежуточные прокси нас понимают верно и могут помочь показывает, что метод выбран правильно.
Тут POST download приведен как сценарий в котором нам мешает отсутствие pipelining'а таких запросов в HTTP/2. Моя точка зрения, что в случае, когда мы делаем пачку последовательных POST запросов:
а) не стоит называть их download
б) либо они не идемпотентны и тогда их лучше не пайплайнить, либо они идемпотенты и тогда их стоит отправлять через PUT.
Здравствуйте, Ikemefula, Вы писали:
I>Я не сильно глубоко знаю про http, какие именно сюрпризы надо ждать ?
Разработчик вправе ожидать, что POST запросы придут на бэкенд последовательно, в нужном порядке. Pipelining эту гарантию убирает.
I>Это устоявшаяся практика. Не я её изобрёл.
Ты ее применил. Вызов API через POST, который ты приводишь в качестве примера, это не download.
I>А вот и не верно. Поднастроил ты конвертор в админке, отправляешь тот же файл второй раз с теми же хидерами. Какой результат ждать ?
Это зависит от настроек кеширования. POST по стандарту не кешируют. Это глагол, который используют для гарантии соответствия порядка вызовов порядку выполнения.
Здравствуйте, Ziaw, Вы писали:
I>>Я не сильно глубоко знаю про http, какие именно сюрпризы надо ждать ?
Z>Разработчик вправе ожидать, что POST запросы придут на бэкенд последовательно, в нужном порядке. Pipelining эту гарантию убирает.
По моему, при разработке бакенда не надо делать никаких предположений вида "запросы придут последовательно"
I>>Это устоявшаяся практика. Не я её изобрёл.
Z>Ты ее применил. Вызов API через POST, который ты приводишь в качестве примера, это не download.
Ты снова злоупотребляешь телепатией. Я указал, а не применил. Разницу чувствуешь ?
Это называется download давным давно, достаточно погуглить по http post download
I>>А вот и не верно. Поднастроил ты конвертор в админке, отправляешь тот же файл второй раз с теми же хидерами. Какой результат ждать ?
Z>Это зависит от настроек кеширования. POST по стандарту не кешируют. Это глагол, который используют для гарантии соответствия порядка вызовов порядку выполнения.
Если "зависит от настроек кеширования", то в этом случае кеш у тебя стал стейтфул сущностью, что уже само по себе проблема. А вот пользователь ожидает, что после изменения настроек он получит ответ с уже примененными настройками.
Здравствуйте, Ikemefula, Вы писали:
I>По моему, при разработке бакенда не надо делать никаких предположений вида "запросы придут последовательно"
Почему? Не идемпотентные операциии должны приходить в нужном порядке, если на это нельзя рассчитывать, на бэкэнде придется городить очень сложные и хрупкие механизмы по искусственному выстраиванию этого порядка.
I>Ты снова злоупотребляешь телепатией. Я указал, а не применил. Разницу чувствуешь ?
Не чувствую.
I>Это называется download давным давно, достаточно погуглить по http post download
И что же показывает твой гугл? Мой показывает ссылки:
Is it possible to download a file with HTTP POST? — Stack Overflow
HTTP Download of large file with POST-Request — Chilkat Forum
Downloading a file via HTTP post and HTTP get in C# — Techcoil Blog
File download using HTTP request — Pulkit Goyal
Везде идет речь про скачивание файла и нигде нет твоего "устоявшегося" термина. Я не знаю, что это за практика и где ты ее нашел. Нигде не встречал, чтобы вызов API через POST назывался http POST download. Для чего ты сейчас настаиваешь на его употреблении?
I>Если "зависит от настроек кеширования", то в этом случае кеш у тебя стал стейтфул сущностью, что уже само по себе проблема. А вот пользователь ожидает, что после изменения настроек он получит ответ с уже примененными настройками.
Не получится выбрать потенциально кешируемый метод и не зависеть от настроек кеширования. Я напомню с чего мы начали, я попросил пример, где нужен pipelining запросов POST. Ты приводишь примеры где POST не лучший выбор и меняешь требования на ходу. Сначала требуешь реализовать stateless сервис, потом требуешь чтобы он перестал быть stateless.
Здравствуйте, Ziaw, Вы писали:
I>>По моему, при разработке бакенда не надо делать никаких предположений вида "запросы придут последовательно"
Z>Почему? Не идемпотентные операциии должны приходить в нужном порядке, если на это нельзя рассчитывать, на бэкэнде придется городить очень сложные и хрупкие механизмы по искусственному выстраиванию этого порядка.
I>>Ты снова злоупотребляешь телепатией. Я указал, а не применил. Разницу чувствуешь ? Z>Не чувствую.
Если я указываю на существование некоего явления, из этого никак не следует, что у себя в проекте я сделал ровно то же.
А вот с твоей точки рения это одно и то же, потому как разницы, по твоим же словам, не чувствуешь.
I>>Это называется download давным давно, достаточно погуглить по http post download Z>И что же показывает твой гугл? Мой показывает ссылки:
Z>Is it possible to download a file with HTTP POST? — Stack Overflow Z>HTTP Download of large file with POST-Request — Chilkat Forum Z>Downloading a file via HTTP post and HTTP get in C# — Techcoil Blog Z>File download using HTTP request — Pulkit Goyal
Z>Везде идет речь про скачивание файла и нигде нет твоего "устоявшегося" термина.
То есть, "устоявшаяся практика" ты читаешь как "устоявшийся термин" ? Блеск!
Читаем вместе — почти все результаты с первой страницы про скачивание через метод Post по протоколу HTTP. Самая первая ссылка датирована еще 11м годом, а чуть дальше и вовсе 2006й год. Дальше, если ты не заметил, у первой ссылки есть кучка похожих, ровно про то же. Вот это и значит, что вещь уже давным давно известна и применяется.
I>>Если "зависит от настроек кеширования", то в этом случае кеш у тебя стал стейтфул сущностью, что уже само по себе проблема. А вот пользователь ожидает, что после изменения настроек он получит ответ с уже примененными настройками.
Z>Не получится выбрать потенциально кешируемый метод и не зависеть от настроек кеширования. Я напомню с чего мы начали, я попросил пример, где нужен pipelining запросов POST. Ты приводишь примеры где POST не лучший выбор и меняешь требования на ходу. Сначала требуешь реализовать stateless сервис, потом требуешь чтобы он перестал быть stateless.
Конверсия как была, так и осталась стейтлесс. А вот если добавить вещи типа "поставить на паузу", "продолжить", "повторить два предыдущих шага конверсии" — вот это будет стейтфул. И нигде ничего подобного я не просил.
Тебя не смущает, что у стейтлесс сервисов есть база данных, сторадж, и они от этого не перестают быть стейтлесс?
Здравствуйте, Ikemefula, Вы писали:
I>Если я указываю на существование некоего явления, из этого никак не следует, что у себя в проекте я сделал ровно то же. I>А вот с твоей точки рения это одно и то же, потому как разницы, по твоим же словам, не чувствуешь.
Я не утверждал, что ты что-то применяешь в проекте. Речь шла про применение термина.
I>То есть, "устоявшаяся практика" ты читаешь как "устоявшийся термин" ? Блеск!
Если ты вводишь термин и на указание о его не соответствии говоришь, что это устоявшаяся практика, именно так и читаю.
I>Читаем вместе — почти все результаты с первой страницы про скачивание через метод Post по протоколу HTTP. Самая первая ссылка датирована еще 11м годом, а чуть дальше и вовсе 2006й год. Дальше, если ты не заметил, у первой ссылки есть кучка похожих, ровно про то же. Вот это и значит, что вещь уже давным давно известна и применяется.
Какая вещь известна и применяется? Если скачивание файлов, про которое говорит гугл, то зачем ему pipelining?
I>Конверсия как была, так и осталась стейтлесс. А вот если добавить вещи типа "поставить на паузу", "продолжить", "повторить два предыдущих шага конверсии" — вот это будет стейтфул. И нигде ничего подобного я не просил. I>Тебя не смущает, что у стейтлесс сервисов есть база данных, сторадж, и они от этого не перестают быть стейтлесс?
Не вижу смысла обсуждать толкование stateless. Что именно ты понимаешь под термином "http post download" которому мешает отсутствие pipelining?
Здравствуйте, ·, Вы писали:
·>Ну если только косвенно. Ничто не мешает поменять hg хранилище на аналогичное git (ну кроме разве что совместимости). Unix-way оно от этого не станет.
Тогда будет проще большинство операций делать простыми инструментами, которые заточены под конкретную мелкую задачу. Разработчики это быстро поймут и hg начнет двигаться в сторону unix-way. Вопрос не в количестве экзешников, а в универсальности элементарных операций.
И наоборот, когда разработка начинается с простых инструментов, структура хранилища проектируется так, чтобы им было удобно.
Здравствуйте, Ikemefula, Вы писали:
_>>С такими то тестами можно получить любой желаемы эффект.
I>А что не так с тестами?
Синтетические сильно: сейчас большинство фреймворков по умолчанию дают упаковку скриптов и стилей (и в некоторых случаях изображений), так что во многих случаях получается 3-5 файлов (включая саму страницу). С другой стороны массовая загрузка библиотек скриптов идёт с CDN, Yandex, google и прочего — т.е. отдельные соединения ко множеству сайтов, и фичи HTTP2 не так уж заметны в этом случае (грузится малое количество файлов из большого количества источников). Ну и 1000 запросов это само по себе синтетика — нужно специально постараться чтобы получить подобное в реальном проекте.
Здравствуйте, Ziaw, Вы писали: Z>Какая вещь известна и применяется? Если скачивание файлов, про которое говорит гугл, то зачем ему pipelining?
Ты похоже вообще не читаешь. I>>Конверсия как была, так и осталась стейтлесс. А вот если добавить вещи типа "поставить на паузу", "продолжить", "повторить два предыдущих шага конверсии" — вот это будет стейтфул. И нигде ничего подобного я не просил. I>>Тебя не смущает, что у стейтлесс сервисов есть база данных, сторадж, и они от этого не перестают быть стейтлесс? Z>Не вижу смысла обсуждать толкование stateless. Что именно ты понимаешь под термином "http post download" которому мешает отсутствие pipelining?
Кейс — юзер жмет кнопку и у него в браузере показывается окошко "download". Щас, похоже, ты будешь неделю уточнять что это такое ?
На всякий
Какой метод используется — по разному, чаще GET, но бывает и POST.
Теперь надо вспомнить историю веба. Поначалу всякие методы типа put, delete были дикой экзотикой и не проходили через промежуточные прокси и фаерволы.
Было два основных метода — get и post.
Post — через это работала самая обычная кнопка сабмит. Как закинуть файл на сервер ? Сабмит. Сабмит. Сабмит.
А как быть, если сервер не хранит промежуточное состояние, но надо реализовать навроде конвертора ? Сабмит. Сабмит. Сабмит. Сабмит. Сабмитаешь один файл, в респонсе получаешь другой.
Эта вещь такая же старая, как и весь интернет.
Почему нужен пайплайн — для тех же целей, что и в других случаях.
GEt имеет фундаментальное ограничение — в строку адреса и квери много не напихаешь. Как отсылать данные на сервер ? POST.
А если надо отослать данные на сервер и сразу принять их целую кучу ? Ну, скажем, обычный json из которого будет рендериться часть страницы на клиенте ? Делать два реквеста ? Зачем, если можно одним ?
Как реализовать функционал навроде конвертора если сервер не хранит промежуточное состояние ? POST.
Итого, основных вариантов http download всего два — get и post. Разница только в приседаниях со стороны браузера, для post надо делать дополнительные приседания, что бы вызвать то самое окошко.
Здравствуйте, Somescout, Вы писали:
_>>>С такими то тестами можно получить любой желаемы эффект.
I>>А что не так с тестами?
S>Синтетические сильно: сейчас большинство фреймворков по умолчанию дают упаковку скриптов и стилей (и в некоторых случаях изображений), так что во многих случаях получается 3-5 файлов (включая саму страницу). С другой стороны массовая загрузка библиотек скриптов идёт с CDN, Yandex, google и прочего — т.е. отдельные соединения ко множеству сайтов, и фичи HTTP2 не так уж заметны в этом случае (грузится малое количество файлов из большого количества источников). Ну и 1000 запросов это само по себе синтетика — нужно специально постараться чтобы получить подобное в реальном проекте.
Понятно, что синтетические. Такие тесты показывают, за счет чего будет профит и где именно.
Во первых, до сих пор слишком часто пишут, что де ручной бандлинг уже анти-паттерн, что де http2 всё разрулит как надо, что его мультплексор сделает всё в лучшем стиле. Я одно время даже поверил, потому что это приводилось в одной из книг, что я читал.
Во вторых, я, например, вижу, что все http2 версии сайтов работают намного быстрее и сильно замедляются, если отключить http2.
