Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Стандартизирован HTTP-метод QUERY, комбинирующий возможности GET и POST"	+/–
Сообщение от opennews (??), 18-Июн-26, 09:36
Инженерный комитет IETF (Internet Engineering Task Force), занимающегося развитием протоколов и архитектуры сети Интернет, придал HTTP-методу QUERY статус "Предложенного стандарта" и опубликовал связанную с ним спецификацию RFC 10008. Метод QUERY по  способу отправки данных на сервер повторяет метод POST, но отличается от него ориентацией не на запись данных и изменение состояния, а на формирование запросов на чтение... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=65713
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–15 +/–
Сообщение от Аноним (1), 18-Июн-26, 09:36
И так браузеры еле работают, простое открытие хрома, файрфокса, браве без отображения страниц запускает по 25-30 процессов, жрет память и процессор...
Ответить | Правка | Наверх | Cообщить модератору

	7. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–7 +/–
	Сообщение от q (ok), 18-Июн-26, 10:21
	Обнови комп. Удали нескучные расширения. Закрой миллиард вкладок, которые накопились на 20 лет бравзинга (я же знаю, что ты их не закрываешь - видел у тебя на скринах, от табов только узенькие полоски, на которые даже кнопка закрытия вкладки не умещается).
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–2 +/–
	Сообщение от Аноним (11), 18-Июн-26, 10:27
	Почикать совместимость с целыми поколениями железа. Это конечно сильно.
	Ответить | Правка | Наверх | Cообщить модератору

	113. Скрыто модератором	+1 +/–
	Сообщение от ы (?), 19-Июн-26, 07:26
	Прекращай юзать 486dx
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним324 (ok), 19-Июн-26, 18:38
	Давно пора почикать, и почикать конкретно, нужно убрать поддержку всего что было до 2015 года как минимум. Это сразу разгрузит и браузер, и сервера и всем станет проще.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	17. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+8 +/–
	Сообщение от анон (?), 18-Июн-26, 10:44
	Обнови комп. Удали нескучные расширения. Закрой миллиард вкладок, которые накопились на 20 лет бравзинга. Выбери жизнь. Выбери работу. Выбери карьеру. Выбери семью. Выбери телевизор с большим экраном. Выбери стиральную машину, музыкальный центр, автомобиль и электрический консервный нож. Выбери здоровый желудок, зубы и медицинскую страховку. Выбери недвижимость и аккуратно выплачивай взносы. Выбери свой первый дом. Выбери друзей. Выбери курорты и шикарные чемоданы. Выбери костюм-тройку в самой лучшей фирме из самой дорогой материи. В свой выходной выбери диван, чтобы развалиться и смотреть отупляющее шоу. Набивай брюхо всякой всячиной. Выбери загнивание, в конце концов, и со стыдом вспомни подонков, которых ты заложил, чтобы выбраться самому. Выбери своё будущее. Выбери жизнь.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	26. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+2 +/–
	Сообщение от Жироватт (ok), 18-Июн-26, 11:02
	Обнови комп. Удали нескучные расширения. Закрой миллиард вкладок, которые накопились на 20 лет бравзинга. Выбери жизнь. Выбери работу. Выбери карьеру. Выбери семью. Выбери смарт-телек на ведроиде с большим, полутораметровым экраном. Выбери робота-пылесоса, голосового ассистента-в-колонке, электромобиль-Теслу и очередной сверхполезный гаджет с Алиэкспресс. Выбери здоровый желудок, зубы и ДМС. Выбери квартиру-апартаменты внутри МКАДа и аккуратно выплачивай ипотеку. Выбери свою первую дачу. Выбери друзей. Выбери сказочное_бали, Хайнань и невскрываемые бронированные чемоданы. Выбери мешковатый костюм от самой дизайнерской фирмочки МСК из самой дорогой, хотя бы без примесей полиэстера и вискозы, материи. В свой выходной выбери диван, чтобы развалиться и смотреть отупляющие видосы с ю- и рутуба. Набивай брюхо всякой дешёвой и илитной всячиной. Выбери загнивание, в конце концов, и со стыдом вспомни подонков, которых ты заложил, чтобы выбраться самому. Выбери своё будущее. Выбери жизнь. Адаптировать надо, адаптировать. Текст актуален для Штатов 90х-00х, но уже не для СНГ второй половины 20х.
	Ответить | Правка | Наверх | Cообщить модератору

	121. Скрыто модератором	+/–
	Сообщение от Аноним (121), 19-Июн-26, 09:49
	Это была Шотландия.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от bublick (ok), 18-Июн-26, 20:03
	красиво
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	84. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+1 +/–
	Сообщение от Аноним (84), 18-Июн-26, 15:46
	В нынешних браузера окрытые вкладки - незагруженные вкладки, пока по ним явно не ткнёшь.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	122. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от YetAnotherOnanym (ok), 19-Июн-26, 09:53
	> Закрой миллиард вкладок В НИХ ВСЯ МОЯ ЖИЗНЬ!!!!!1111
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	15. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+1 +/–
	Сообщение от aname (ok), 18-Июн-26, 10:42
	А поддерживаемые методы тут причём?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	94. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (94), 18-Июн-26, 17:09
	И поэтому не надо пофиксить в протоколе очевидную ошибку дизайна? Как названия команд HTTP конкретно жрут у тебя память и процессор?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+12 +/–
Сообщение от Аноним (2), 18-Июн-26, 09:53
https://xkcd.com/927/ Раньше разработчики срались из-за организации поиска на POST вместо GET когда надо изобразить что-то сложное. Теперь будут сраться в выборе из 3 методов, великолепно.
Ответить | Правка | Наверх | Cообщить модератору

	5. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+2 +/–
	Сообщение от 1 (??), 18-Июн-26, 10:04
	Нормик - как раз для "плутания" надо не меньше 3 "сосен". Больше - лучше !
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–1 +/–
	Сообщение от Аноним (42), 18-Июн-26, 11:57
	Теперь будут гадать почему в ответ прилетает протухший кэш. POST то никто в адеквате не кэширует
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	52. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–1 +/–
	Сообщение от penetrator (?), 18-Июн-26, 12:33
	срались только долбанариумы, GET в принципе не нужен для API, это просто семантика GET надо только для подсасывания ресурсов самим браузером теперь все будут использовать QUERY но только не в старых версиях браузеров, но цирк сохранится
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	58. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от qrKot (?), 18-Июн-26, 13:05
	А версия браузера тут при чем??? Браузер сам по себе ничего, кроме GET и POST не умеет, остальное JS делает. А метод в запросе - просто строка, чо хошь, то и пиши.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от penetrator (?), 18-Июн-26, 13:09
	> А версия браузера тут при чем??? > Браузер сам по себе ничего, кроме GET и POST не умеет, остальное > JS делает. А метод в запросе - просто строка, чо хошь, > то и пиши. VERB должен поддерживаться браузером, с полной реализацией связанной с методом спецификации начиная например от длины GET запроса, до конкретных поддерживаемых Content-Type в том же POST
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+1 +/–
	Сообщение от qrKot (?), 18-Июн-26, 15:16
	>> VERB должен поддерживаться браузером, с полной реализацией связанной с методом спецификации Открываем дебажную консольку браузера, пишем там: fetch('http://127.0.0.1:8080', {method: 'QUERY'}).then(resp => { console.log(resp)}); Видим ответ. ЧЯДНТ?
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+1 +/–
	Сообщение от YetAnotherOnanym (ok), 19-Июн-26, 09:55
	> ЧЯДНТ? Пытаешься всерьёз писать что-то конкретное в каментах на Опеннете.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (120), 19-Июн-26, 09:25
	Есть ещё атрибут method в <form>, который в свою очередь может быть переопределён атрибутом formmethod в <input> и <button>. Так можно без JS реализовать не только QUERY, но и HEAD, PATCH, DELETE...
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

3. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–3 +/–
Сообщение от Хрю (?), 18-Июн-26, 09:57
>метод POST, но отличается от него ориентацией не на запись данных и изменение состояния, С какого времени пост стал ориентированным на запись и изменение состояния? Пост это пост, какой смысл ему веб. Сервер придаст такой и будет у него смысл. У меня пост readonly, а для изменения есть put, patch, delete.
Ответить | Правка | Наверх | Cообщить модератору

	8. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+8 +/–
	Сообщение от Аноним (8), 18-Июн-26, 10:25
	По классике пост для создания, пут для изменения, патч для изменения части, делит для удаления. И гет для получения
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–7 +/–
	Сообщение от Хрю (?), 18-Июн-26, 10:39
	Этому уже очень давно мало кто следует ибо это сильно узко и не удобно. Для современных браузеров и веб. серверов это просто слова, возможно, с небольшими настройками по умолчанию, для легаси. Но так хоть гет делай для изменений, хоть делете кешируемый всё это будет работать.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–2 +/–
	Сообщение от qrKot (?), 18-Июн-26, 13:06
	>> Для современных браузеров и веб. серверов это просто слова Бгг, особенно для ingress'ов и реверс-прокси, ага.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Олег (??), 19-Июн-26, 08:33
	Согласен. Некомпетентных ураков полно. Но это не значит, что нам надо на них ориентироваться.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	53. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–1 +/–
	Сообщение от penetrator (?), 18-Июн-26, 12:36
	кто сделал это классикой? а если сценарий отработки предполагает вызов внешнего сервиса и тип операции определяется внешним сервисом? тогда что? стройная (нет) семантическая модель идет лесом? )))))) я не использую вообще семантику HTTP для API, это бред, одни статус коды чего стоят лучше обращать на технические ограничения и особенности использования VERBS а не вот это вот всё
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	61. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от qrKot (?), 18-Июн-26, 13:09
	>> а если сценарий отработки предполагает вызов внешнего сервиса и тип операции определяется внешним сервисом? А каким образом твоему API-контракту не насрать на контракт внешнего сервиса? Ну вот пришел тебе PUT-запрос - тебе что-то мешает в коде его обработки POST к внешнему сервису сделать?
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Олег (??), 19-Июн-26, 08:36
	Дело не а классике, а в том, что авторами оно задумывалось вот так. Не понял идеи, не осилил подход - твоё дело. Можешь использовать http через задницу. Он в ответ ничего не скажет. Как одарённые авторы soap, у которых любой запрос это post. Слава богу этот уродец в последнии годы уже сдыхает.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	128. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от rshadow (ok), 19-Июн-26, 16:08
	В современном мире POST-а реально достаточно всем. Я имею ввиду именно на функциональном уровне, чтобы все работало. GET запрос кешируемый, а потому как правило для статики используется. PUT, PATCH и т.д. попытка сделать универсально, но по факту бесполезно. Хочкшь используй, хочешь нет - разницы никакой. Скорее если и используется, то как сахар для роутинга или мониторинга.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+2 +/–
	Сообщение от qrKot (?), 18-Июн-26, 10:59
	>> С какого времени пост стал ориентированным на запись и изменение состояния? Собственно, всегда был. Ну, точнее, немного не так. В этих ваших интернетах больше роляет ИДЕМПОТЕНТНОСТЬ запроса. И вот GET (бай дизайн) - идемпотентный (т.е. его можно безопасно закешировать, что важно, с учетом ограниченности, например, пропускной способности этих ваших интернетов). Т.е. GET дает гарантию, что два-десять-стопицот одинаковых запросов подряд по результату не будут отличаться от одного запроса. POST же - ровно тот же GET, только без всяких гарантий. У него нет гарантий идемпотентности, что по сути говорит о том, что состояние он в любой момент поменять может.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	38. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–1 +/–
	Сообщение от Bonifatium (?), 18-Июн-26, 11:49
	> GET (бай дизайн) - идемпотентный > GET дает гарантию за это отвечает приложение. GET сам по себе не дает гарантий.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (42), 18-Июн-26, 11:59
	За это надо бить разрабов приложения, потому что мутировать данные в GET - это ССЗБ
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Анонисссм (?), 18-Июн-26, 12:20
	>бить разрабов приложения, потому что мутировать данные в GET - это ССЗБ сюрприз, данные могут меняться даже без запросов
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Другой Аноним (?), 18-Июн-26, 14:06
	Сюрприз будет пользователям сайта и админам, когда веселящийся пользователь оставит комментарий, похожий на этот: 
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от qrKot (?), 18-Июн-26, 12:58
	>> за это отвечает приложение. GET сам по себе не дает гарантий. Ну, по сути, у нас тогда вообще никаких гарантий нет. У нас даже нет гарантии, что приложение в принципе запустится! И гарантий, что приложение СООТВЕТСТВУЕТ спецификации - у нас тоже нет. Да и, по большому счету, если приложенька на локалхосте крутится - да кому какая разница на спеки! Работает как-то и ладно! Просто потом сюрпризы начинаются. Деплоишься на новый хостинг - все раком стоит. А разраб такой "ничего не знаю, у меня все работает!" Если приложение корректно и соответствует спеке - GET должен давать гарантию идемпотентности. Иначе говно он, а не GET)
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	54. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от penetrator (?), 18-Июн-26, 12:38
	не дает, потому что данные могут поменяться, и один и тот же гет будет выдавать уже обновленные данные только если ты не захочешь делать версионирование по хешу, но это бред хранить это все, скажем так - это узко специализированное решение
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	57. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–1 +/–
	Сообщение от qrKot (?), 18-Июн-26, 13:02
	Гарантия идемпотентности не в том, что данные никогда не меняются - это в принципе невозможная гарантия. Гарантия идемпотентности - это гарантия, что N повторяющихся запросов (при любом натуральном N) идентичны по своему результату одному аналогичному запросу.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (98), 18-Июн-26, 17:39
	""" Идемпотентная операция в информатике — действие, многократное повторение которого эквивалентно однократному. Примером такой операции могут служить GET-запросы в протоколе HTTP. По спецификации, сервер должен возвращать идентичные ответы на идентичные GET-запросы (при условии, что ресурс не изменился). Это позволяет корректно кэшировать эти ответы, снижая нагрузку на сеть. """ > Гарантия идемпотентности - это гарантия, что N повторяющихся запросов (при любом натуральном N) идентичны по своему результату одному аналогичному запросу. вы забыли про "при условии, что ресурс не изменился", и слово гарантия тут совсем не к месту, нет никаких гарантий, клиент кеширует ответ GET запроса смотря на заголовки кеширования!!! И веб сервер в свою очередь не может давать никаких гарантий, ибо данные изменяет приложение.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (98), 18-Июн-26, 13:55
	> В этих ваших интернетах больше роляет ИДЕМПОТЕНТНОСТЬ запроса. расскажи это сайтам, где на главной странице висит текущее время
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	80. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от qrKot (?), 18-Июн-26, 15:23
	ТЕКУЩЕЕ ВРЕМЯ: <script type='js'> Date.now(); </script> Ты про это?
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (98), 18-Июн-26, 15:52
	нет, что-то вроде page generated time, тип такого, или какое-нибудь стартовое значение для js счетчика.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (94), 18-Июн-26, 17:20
	Вот по таким вот "открытиям чудным" и палятся теоретики, практики не нюхавшие. Идемпотентность нужа только там, где она нужна. Для времени, состояния счётчиков посещений, набора рекламных баннеров, и прочего подобного кружева идемпотентность совершенно не имеет никакой практической ценности, и гоняться за ней будет только совсем уж неумный джун.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	97. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (98), 18-Июн-26, 17:32
	> Идемпотентность нужа только там, где она нужна. лол, тут главный вопрос вы упустили, "нужа" она кому? серверу или клиенту?
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–1 +/–
	Сообщение от Хрю (?), 18-Июн-26, 19:09
	Кошмар - сколько набежало сферических теоретиков в вакууме, которые за пределами hello world 20 летней давности, не нарисовали ни одного рест сервиса. Ну пусть дальше пофантазируют.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	126. Скрыто модератором	+1 +/–
	Сообщение от Аноним (126), 19-Июн-26, 10:52
	показывай свои, трепло
	Ответить | Правка | Наверх | Cообщить модератору

4. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+5 +/–
Сообщение от Аноним (4), 18-Июн-26, 10:03
А кто вам запрещает в GET вставлять ненулевое тело? HTTP это не запрещает, да и я так делал и делаю
Ответить | Правка | Наверх | Cообщить модератору

	10. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+1 +/–
	Сообщение от фф (?), 18-Июн-26, 10:26
	а кто запрещает не изменять данные по POST запросу (если логика подразумевает лишь выдачу информации)? или может кто-то запрещает кешировать ответ на такой запрос? Почему тогда уж не сделать один универсальный метод запроса, а в заголовках указывать - можно ли кешировать, можно ли писать в логи итп.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–1 +/–
	Сообщение от qrKot (?), 18-Июн-26, 11:27
	>> а в заголовках указывать - можно ли кешировать Ну ващет можно указывать. Прям заголовки специальные есть даже. Вот тут с механикой ознакомиться можно: https://datatracker.ietf.org/doc/html/rfc2616#section-13 >> а кто запрещает не изменять данные по POST запросу Никто не запрещает. И изменять никто не запрещает. По факту - POST-запрос вообще без всяких гарантий, может делать все, что угодно. Это специальный такой запрос без семантики вообще. >> или может кто-то запрещает кешировать ответ на такой запрос? Здравый смысл, например? Метод не гарантирует идемпотентность - что вы кешировать собрались? >> Почему тогда уж не сделать один универсальный метод запроса На JSON-API посмотрите - один универсальный POST, везде 200-Ок в ответах. HTTP - строго транспорт, вся информация об ошибках и т.д. - в BODY. За пределами же API-применения на локальной машинке есть всяческие border-gateway и реверс-прокси, маппинг, CORS'ы и прочее-прочее, которым удобнее иметь методы и заголовки.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от фф (?), 18-Июн-26, 12:20
	это всё понятно. Моя мысль была про зачем выдумывать новые методы, если можно всё это реализовать на уже имеющихся? про идемподентость вот только - а кто ее гарантирует в гет запросе, или вот в этом новом? сервер вполне и базу может грознуть и диск отформатировать после первого гет, и на второй уже физически не сможет прочитать инфу для ответа. Идемпотентность можно задекларировать в апи. И тогда пофиг как вы будете слать запросы - soap вон вобще по smtp умеет работать - ответы можно будет кешировать.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от qrKot (?), 18-Июн-26, 13:30
	>> про идемподентость вот только - а кто ее гарантирует в гет запросе, или вот в этом новом? Реализация от разработчика сервиса, очевидно! Спецификации эти - они для чего, собственно, нужны? Да для того, чтобы минимум удивления было при отладке и поиске багов в продовых окружениях! Пока приложенька запущена на локалхосте с единственным пользователем из браузера на том же локалхосте - можно смело забить на все эти спецификации. Это "набор рекомендаций, не более того" (с) некий Джек Воробей. Вопрос только в том, что будет дальше. Вот раскатался ты на какой-нибудь клауд-нейтив диджитал-оушен, радостный сидишь. А потом не радостный ищешь, какого хрена ничего не работает. Просто у хостера есть border-gateway. А еще хостер знает, что GET должен быть идемпотентным. Ну вот пришел ему запрос GET /some/path - он его у тебя запросил, пользователю вернул, в кеше у себя прихранил. Пришел второй через секунду - а хостер решает "не буду лишний раз стучаться" и отдает ответ из кеша. А ты сидишь, как олень, и пытаешься понять, почему до тебя запросы не доходят, а у пользователей данные устаревшие. Короче, хочешь без сюрпризов - изволь соответствовать спеке! >> Моя мысль была про зачем выдумывать новые методы, если можно всё это реализовать на уже имеющихся? Не получится, да и запутаются все. Вот тут полный тред народа, которые в GET обработку body юзают (я тоже юзаю, на самом деле, но во внутреннем интеропе). А перед всеми этими тысячами приложенек, каждая со своей хотелкой, стоят реверс-прокси, ингрессы всякие и т.д. и т.п. Хостеры, короче, как-то трафиком рулят. Ну вот представь себя хостером. Тебе оно надо свой гейтвей напрягать и всякие мегабайтные body и прочие payload'ы парсить, чтобы понять, что закешировать надо, и как эти запросы отбалансить? А логику кеширования и балансировки ты будешь под каждый возможный ингресс в каждом своем приложении писать? А ты точно не рукожоп и проксю не положишь? Ну вот они и рожают спецификации, чтобы без этих вот приседаний и 100-километровых мануалов было понятно: вот вам QUERY, вот у него 4 заголовка, которые регулируют политику кеширования. И ты читаешь, и в 50 строк поддержку пилишь в своем сервисе. А разрабы проксей - ту же самую спеку читают, и из коробки в своей софте поддержку этих заголовков рожают. Охуенно же.
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (16), 18-Июн-26, 10:44
	Вставлять никто не запрещает :) Но стандартный сервер может просто отбросить всё после хэдера и будет прав.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	31. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–1 +/–
	Сообщение от Dmitry (??), 18-Июн-26, 11:07
	Стандартный сервер это какой? Как я напишу, так и будет
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+1 +/–
	Сообщение от qrKot (?), 18-Июн-26, 11:52
	Стандартный - это реверс-прокси или boder-gateway хостера. Что бы ты ни писал, настройкам ингресса на это по барабану.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+1 +/–
	Сообщение от Аноним (33), 18-Июн-26, 11:12
	"стандартный сервер" - это который нарушает хттп спеку? Оставьте такие сервера себе.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	40. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+2 +/–
	Сообщение от qrKot (?), 18-Июн-26, 11:55
	Где нарушает-то? Читаем спеку: '''The GET method means retrieve whatever information (in the form of an    entity) is identified by the Request-URI.''' Метод GET служит для получения любой информации, идентифицируемой Request-URI. Body частью Request-URI не является - можно смело выкидывать.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (20), 18-Июн-26, 10:50
	Ага, причем сразу multipart/form-data, чтобы вообще )))
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	34. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от qrKot (?), 18-Июн-26, 11:14
	Принятые соглашения и сторонние прокси, например? Да, в стандарте напрямую про игнор body ничего не говорится, но там говорится следующее: ```The GET method means retrieve whatever information (in the form of an    entity) is identified by the Request-URI.``` Ну т.е. "запрос для получения информации, идентифицируемой Request-URI". А body в Request-URI не входит, т.е. запросы с одинаковой урлой и разными body, согласно стандарту, должны возвращать одну и ту же информацию. На основании этого есть СОГЛАШЕНИЕ об идемпотентности запроса. Пока ты на локалхосте пилишь сайты на PHP, по сути, никто тебе не запретит body в GET-запросе читать или аплоадить фоточки GET-запросом через multipart-form. Однако как только ты чуть-чуть за пределы локалхоста выберешься... Ну задеплоился ты, например, в какой-нибудь гуглоклауд-апп-энжин, а потом удивляешься, почему тебе body в GET-запросах не приходит, например...
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	36. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от фняк. (?), 18-Июн-26, 11:42
	Просто решили в стандарте прописать явным образом. Давно ковырял, но была там какая-то неоднозначность, хотя на практике работало
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	70. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (98), 18-Июн-26, 13:52
	в том то и дело, просто веб сервера - игнорят тело, а всякие waf-ы - проигнорят весь запрос сославшись на ddos, вот и накостыляли ради этого новый метод, чтобы ничего не ломать, вот так и обрастает протокол костылями.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

6. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
Сообщение от вымя (?), 18-Июн-26, 10:04
И, эээээ, чем это отличается от PUT?
Ответить | Правка | Наверх | Cообщить модератору

	13. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Жироватт (ok), 18-Июн-26, 10:41
	...Но другая группа в IETF нашла в PUT фатальный недостаток - его писали не они! Для решения этой проблемы они создали QUERY (похожее на PUT, но другое), и я наивно вспоминаю докладчика на IETF-овской конференции, говорящего, что скоро все хттп-запросы будуи ходить исключительно как QUERY через QUIC, и каждая обёртка над серверным API на экране будет исключительно QUERY-ем...
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (19), 18-Июн-26, 10:49
	И чем же это будет отличаться от текущего балагана, кроме того что его просто узаконят и подметут в помойку бесконечно растущих хедеров?
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+1 +/–
	Сообщение от Жироватт (ok), 18-Июн-26, 10:54
	Ничем.  "xckd - 15й стандарт". Но с другой стороны - зря что ли инженегры зарплату в этих комитетах получают? Нужно рожать Новый&УлуДшенный стандарт даже через "не могу", иначе кто заметит усилий.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (30), 18-Июн-26, 11:06
	Это GET-овый PUT, как будто бы.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	45. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+1 +/–
	Сообщение от qrKot (?), 18-Июн-26, 12:00
	Кхм, а что у него общего с PUT? PUT - создай/измени запись. QUERY - выбери мне данные, удовлетворяющие запросу, который лежит в body.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	100. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от вымя (?), 18-Июн-26, 18:03
	> а что у него общего с PUT? Всё введение в RFC о том, что «мы хотим тела как в POST и идемпотентность». Так вот же, уже есть. Что новость, что оригинал сформулированы так, что ни за что не догадаешься, кому это может быть нужно. Сразу чувствуется школа писателей куберовских спеков.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (98), 18-Июн-26, 18:31
	> «мы хотим тела как в POST и идемпотентность» нет, главный посыл в том, что "мы хотим GET с body", обычное изменение механики GET сломает Ынтернет, ибо веб сервера на данный момент полностью игнорируют body у GET, а всякие waf-ы такие запросы считают мусорными, и чтобы не сломать все к х3рам, накостыляли новый метод.
	Ответить | Правка | Наверх | Cообщить модератору

18. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
Сообщение от Аноним (20), 18-Июн-26, 10:48
QUERY энтерпрайзно. Изживают потихонечку хакерскую культуру, выдавливают по капле.
Ответить | Правка | Наверх | Cообщить модератору

22. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+2 +/–
Сообщение от localhostadmin (ok), 18-Июн-26, 10:56
Я не совсем понял. Че  оно отличается от обычного POST? В чем проблема принимать POST запросы и обрабатывать их как QUERY?
Ответить | Правка | Наверх | Cообщить модератору

	29. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–1 +/–
	Сообщение от Жироватт (ok), 18-Июн-26, 11:06
	Стандарты мутятся - лавэшка (на миграциях, переписывании и доработках) крутится. А потом отключат и GET, и POST для защиты детей от Ынтернета^W^W^W^W безопасности парсеров от хакеров и всё. Будет тебе кури вместо 2х типов запросов
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+3 +/–
	Сообщение от Аноним (33), 18-Июн-26, 11:10
	POST - семантически про изменение данных. Query/get - про чтение данных, ожидая, что состояние запрашиваемых данных от этого запроса не изменится.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	47. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+1 +/–
	Сообщение от qrKot (?), 18-Июн-26, 12:11
	У POST особой семантики нет. POST - это "вот запрос к серверу, отдай как есть, сервер сам знает, что с этим делать". POST может запрашивать данные, изменять данные, создавать, удалять - да все может (с точки зрения семантики). QUERY - больше про выборку данных. Фильтры, запросы "отдай мне пользователей с датой рождения позднее 2006 года" и т.д. Условно SELECT-запросы. По факту, запрета на изменение данных нет, и в случае неидемпотентных запросов действительно от POST не отличается. Зато для идемпотентных (SELECT-запросов) есть механика со специальными заголовками про кеши/протухание кешей/ссылками на повтор запроса/ссылками на получение данных из прошлых запросов. Кажется, конечно, что херня ненужная, но это если не задумываться о реверс-прокси и прочих border-gateway'ях. Вот пришел к тебе запрос "выбери мне всех блондинов с голубыми глазами и членом 35 см." - ты в базу сходил, получил мой профиль, и в кеше у себя прихранил. Наружу отдал заголовки "за следующую минуту вряд ли чего изменится", "данные запроса я у себя храню в кеше следующий час по ссылке1" и "повторно запросить можно по ссылке2". Следующий запрос через 30 секунд отдастся прямо из кеша реверс-прокси (до тебя даже не дойдет, нахрена тебе лишние запросы). Потом еще час запросы будут отдаваться из твоего уже кеша, и только через час оно начнет опять в базу ломиться. Офигительно же. И двухуровневый кеш самому пилить не надо, тупо заголовки правильно расставь.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

23. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–2 +/–
Сообщение от Соль земли2 (?), 18-Июн-26, 10:58
> даёт возможность скрыть конфиденциальные данные из логов прокси-серверов Решение проблемы через Ж, вместо нормальной настройки прокси.
Ответить | Правка | Наверх | Cообщить модератору

	65. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от qrKot (?), 18-Июн-26, 13:32
	Ох уж эти админы локалхоста, которые и софт пишут, и прокси сами настраивают...
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Соль земли2 (?), 18-Июн-26, 14:14
	Оправдываешь криворукость. Даже если это делает два разных человека - сити вещей не меняет.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от qrKot (?), 18-Июн-26, 15:29
	А если приложеньку настраиваешь ты, а прокси - политики хостера?)))
	Ответить | Правка | Наверх | Cообщить модератору

25. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+2 +/–
Сообщение от IdeaFix (ok), 18-Июн-26, 11:00
Пару дней назад попросил безопасника открыть 43 порт, ну надо мне было whois чтобы банить автономками. Готовая скриптовая оснастка уже была, и в других местах она работала, а тут 43 закрыт. Безопасник сказал - у ripe есть rest api, перепиши свои скрипты под https и не нужен тебе 43 порт. Я конечно сказал что скоро мы и пинговать будем по rest api через https, но пошел переписывать скрипты. А тут вон оно чо... http query.
Ответить | Правка | Наверх | Cообщить модератору

	74. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Соль земли2 (?), 18-Июн-26, 14:18
	пинг по rest api называется healthcheck
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (93), 18-Июн-26, 16:32
	Смотря здоровье чего ты проверяешь. Если "принимает ли кто-то TCP соединения" - то да. Обычно же если у хттп-сервиса есть healthcheck, то это про осмысленный ответ приложения, которое про себя что-то полезное знает, а не просто умеет принимать соединения.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (94), 18-Июн-26, 17:31
	Безопасник всё правильно сказал. Если сам не можешь, попроси ллм, она тебе whois на curl заменит. И вообще, не надо дёргать внешний сервер чтобы банить автономками. Приляжет он от таких вот как ты, и что будешь делать? Банить AS503 gateway timeout? RIPE публикует всё нужное плейнтекстом, чтобы один раз скачать и локально читать.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	104. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от IdeaFix (ok), 18-Июн-26, 19:53
	> Безопасник всё правильно сказал. Если сам не можешь, попроси ллм, она тебе > whois на curl заменит. И вообще, не надо дёргать внешний сервер > чтобы банить автономками. Приляжет он от таких вот как ты, и > что будешь делать? Банить AS503 gateway timeout? RIPE публикует всё нужное > плейнтекстом, чтобы один раз скачать и локально читать. С одной стороны это так, с другой, аликлауд, юклауд и прочие товарищи довольно динамично шуршат в разные сети. А заменить удобный инструмент костылями я и без ллм могу, скоро и пинговать по хттпс будем, вон выше каталожное решение.
	Ответить | Правка | Наверх | Cообщить модератору

28. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+2 +/–
Сообщение от Аноним (33), 18-Июн-26, 11:04
> Подобный подход даёт возможность передавать большой объём параметров в запросе, превышающий лимит на размер параметров в методе GET (8000 байт). Никто и ничто не мешает передавать параметры запроса точно также как в посте - через тело гета. Спека это разрешает. Люди этим пользуются. Единственный "бонус" от появления query - явно описанная семантика в отличие от гета, но так себе. Функционально оно ничего не меняет.
Ответить | Правка | Наверх | Cообщить модератору

	37. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (37), 18-Июн-26, 11:48
	> Спека это разрешает. пруф в студию, пожалуйста. заранее спасибо. с ув.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (93), 18-Июн-26, 16:24
	https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.1-6 Если сервер говорит что он это принимает и обрабатывает - значит можно.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+2 +/–
	Сообщение от qrKot (?), 18-Июн-26, 12:27
	>> Никто и ничто не мешает передавать параметры запроса точно также как в посте - через тело гета. Спека это разрешает. Никто и ничто не мешает реверс-прокси, ингрессам, бордер-гейтвеям и т.д. игнорировать тело запроса при передаче. Спека это разрешает. >> Единственный "бонус" от появления query - явно описанная семантика в отличие от гета The GET method means retrieve whatever information (in the form of an    entity) is identified by the Request-URI. GET-метод служит для получения любой информации (в форме сущности), идентифицируемой Request-URI. В чем "не явная семантика"? 2 важных положения "ПОЛУЧЕНИЕ сущности" и "идентифицируемой Request-URI". Т.е. содержимое body (не часть Request-URI) не может быть используемо для идентификации. Поясню: два GET-запроса с одинаковой урлой, но с разными body должны и обязаны возвращать идентичные ответы (идентичные GET-запросу на ту же урлу вообще без body). Поэтому в спека НЕ ЗАПРЕЩАЕТ передачу body в GET-запросе, но явным образом лишает body GET-запроса всякого смысла. Если body не имеет право изменить что-то в процессинге запроса, нахрена его вообще передавать?
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	92. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (93), 18-Июн-26, 16:29
	> Никто и ничто не мешает реверс-прокси, ингрессам, бордер-гейтвеям и т.д. игнорировать тело запроса при передаче. Спека это разрешает. Никто и ничто не мешает файрволу оборвать твоё TCP соединение потому что ему так захотелось. Никакие спеки это не запрещают. Это на усмотрение тех, кто настраивал файрвол. Тоже самое касается хттп-прокси. > The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. Первое предложение из длинной секции текста - это здорово, но если прочитать секцию целиком то станет видно, что смысла несколько больше, чем одно первое предложение. > Т.е. содержимое body (не часть Request-URI) не может быть используемо для идентификации Важно понимать отличие "should", "may" и "must" в английском языке. Не "не может", а "мы не гарантируем, потому что посредники может решить выкинуть тело". > Если body не имеет право изменить что-то в процессинге запроса, нахрена его вообще передавать? Имеет. Прочитай всю секцию внимательно.
	Ответить | Правка | Наверх | Cообщить модератору

46. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+2 +/–
Сообщение от GrandProgrammer (ok), 18-Июн-26, 12:06
Теперь еще деприкейт GET метода сделают лет через двадцать.
Ответить | Правка | Наверх | Cообщить модератору

48. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–1 +/–
Сообщение от Аноним (48), 18-Июн-26, 12:19
Говорили-же им: не плоди сущности без надобности. Все равно плодят. А что в итоге? >могут напрямую использоваться расширенные форматы, такие как .... SQL (application/sql) что чревато иньекциями, т.к. WAFы не смогут очищать SQL запросы в BODY ЗЫ. Выглядит прямо как сознательная диверсия.
Ответить | Правка | Наверх | Cообщить модератору

	69. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–1 +/–
	Сообщение от Аноним (98), 18-Июн-26, 13:48
	> ЗЫ. Выглядит прямо как сознательная диверсия. все верно, достаточно поглядеть как анбэшные диверсанты саботируют крипту, все подробности тут: //blog.cr.yp.to/
	Ответить | Правка | Наверх | Cообщить модератору

55. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+1 +/–
Сообщение от Аноним (55), 18-Июн-26, 12:45
По GET спецификации можно передавать тело. Зачем новый "квари" потребовался?!
Ответить | Правка | Наверх | Cообщить модератору

	67. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–1 +/–
	Сообщение от qrKot (?), 18-Июн-26, 13:44
	По GET-спецификации GET возвращает данные, идентифицируемые по Request-URI, в котором body не участвует. Т.е. спека официально разрешает его игнорировать.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+1 +/–
	Сообщение от Аноним (93), 18-Июн-26, 16:16
	"Разрешает игнорировать" кому? Тело в гете не запрещено, и разрешено к использованию если про сервер известно, что он придаёт значение телу гета.
	Ответить | Правка | Наверх | Cообщить модератору

59. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
Сообщение от Аноним (59), 18-Июн-26, 13:05
А где же RFC 10000
Ответить | Правка | Наверх | Cообщить модератору

	87. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+1 +/–
	Сообщение от Аноним (84), 18-Июн-26, 15:59
	Вышел 1 апреля. Ещё не придали официального статуса.
	Ответить | Правка | Наверх | Cообщить модератору

63. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+4 +/–
Сообщение от Assador (ok), 18-Июн-26, 13:12
Надо предложить IETF сделать следующим стандартизированным запросом ASK. А после него — WHATTHEFUCK. 1. Метод ASK Используется, когда тебе _очень_ нужно узнать у сервера, почему что-то пошло не так, но ты не хочешь слать тяжелый QUERY. Тело запроса: пустая строка или лаконичное «Ну и?». Ожидаемый ответ: сервер возвращает текущий экзистенциальный статус базы данных. Поддерживает кэширование, потому что ответ «Всё сложно» обычно не меняется неделями. 2. Метод WHATTHEFUCK (или WTF для экономии трафика) Метод наивысшего приоритета. Вызывается автоматически, когда фронтенд получает «500 Internal Server Error», хотя локально всё работало идеально. Идемпотентность: абсолютно неидемпотентен. Каждый вызов этого метода гарантированно повышает давление у дежурного сисадмина.   Заголовки: обязательно должен содержать заголовок «X-Reason: Kuda-Vse-Delos». Спецификация ответа: сервер обязан в ответ прислать не просто JSON с ошибкой, а полный дамп памяти, историю коммитов за последние три часа и контакты тимлида, который это одобрил. Код ответа для такой связки тоже нужен отдельный: «499 I Am Doing My Best». Осталось только оформить черновик RFC, закинуть в список рассылки IETF и ждать, пока суровые бородатые инженеры в свитерах начнут это комментировать с абсолютно серьезными лицами.
Ответить | Правка | Наверх | Cообщить модератору

	75. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от IdeaFix (ok), 18-Июн-26, 14:32
	> Осталось только оформить черновик RFC, закинуть в список рассылки IETF и ждать, > пока суровые бородатые инженеры в свитерах начнут это комментировать с абсолютно > серьезными лицами. А как же HIAS метод? HELPIAMSUCK то есть. Отвечать 200 PFFF
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Проходил мимо (?), 18-Июн-26, 15:36
	Супер 👍
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

66. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
Сообщение от Аноним (48), 18-Июн-26, 13:37
Пока curl не реализует новый метод, тот так и останется на бумаге.
Ответить | Правка | Наверх | Cообщить модератору

68. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+3 +/–
Сообщение от Аноним (68), 18-Июн-26, 13:47
Не понял, почему не достаточно POST. POST - создание, можно рассматривать как создание нового запроса для поиска
Ответить | Правка | Наверх | Cообщить модератору

	77. Скрыто модератором	+/–
	Сообщение от Аноним (20), 18-Июн-26, 14:35
	Потому что POST - это отправить (по почте), а нужно получить (get). Но без ограничений, которые по стандарту накладываются на GET. Я бы не искал здесь логики и здравого смысла. Корпоративные потребности плюс ИИ-шные решения - на выходе хрень.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (99), 18-Июн-26, 17:43
	post, put вот как будто делать нечего разбирать хттп заголовки в контексте приложения, я лет 10 назад написал обвязку для js которая всегда шлет пост с параметрами, упаковывая в json, с минимальными изменениями все переехало в websocket и живет до сих пор, xoчешь классику бери, хочешь приложение пожалуйста.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	108. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+1 +/–
	Сообщение от Аноним (108), 18-Июн-26, 22:55
	Скажу больше, если включить голову, то к любому методу можно вкрутить любую семантику и она будет логически верной.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	117. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Олег (??), 19-Июн-26, 08:39
	Потому, что авторы этого изменения идиоты.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

81. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
Сообщение от zionist (ok), 18-Июн-26, 15:28
Что теперь будет с RESTful API и с паровым отоплением?
Ответить | Правка | Наверх | Cообщить модератору

103. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+1 +/–
Сообщение от fidoman (ok), 18-Июн-26, 19:20
squid например и не пишет в лог после "?", может быть просто убогие прокси сервера надо не использовать?
Ответить | Правка | Наверх | Cообщить модератору

	106. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Аноним (55), 18-Июн-26, 21:07
	Не представляю, каким админом надо быть, чтобы в логи писать тонны параметров запроса...
	Ответить | Правка | Наверх | Cообщить модератору

107. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+4 +/–
Сообщение от Аноним (108), 18-Июн-26, 22:54
А мы, в одном решении, болт клали на стандарты. Т.к. у клиентов разрешено было держать открытым только HTTP, мы под видом HTTP гоняли свой бинарный протокол, а потом клиенты удивлялись, а как так у вас так HTTP быстро работает.
Ответить | Правка | Наверх | Cообщить модератору

110. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	–1 +/–
Сообщение от Tron is Whistling (?), 19-Июн-26, 00:43
Ну короче GET с POST-контентом. Идея нормальная, но вот "присвоение URL и отдача альтернативного URL для GET" - это уже не то, что перебор, это каким-то IPv6 попахивает.
Ответить | Правка | Наверх | Cообщить модератору

111. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
Сообщение от Ilya Indigo (ok), 19-Июн-26, 01:20
В статье объясняется чем новый QUERY отличается от GET что глупо. Объясните чем новый QUERY отличается от POST или PUT и чем не устроили они? P.S. Web-API в подавляющем большинстве просто передают данные в формате applivation/json через POST и никаких проблем не испытывают.
Ответить | Правка | Наверх | Cообщить модератору

114. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
Сообщение от Аноним (114), 19-Июн-26, 07:28
Выглядит как переиначивание HTTP тихой сапой в вариант RPC. Бинарный формат уже сделали два раза, осталось удалить все остальные методы или сделать метод ничтожным (что и делают с каждым новым VERB, как и концепцией REST). Отныне, если QUERY взлетит, любой новый RPC автоматом будет приделан к нему.
Ответить | Правка | Наверх | Cообщить модератору

	118. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от Олег (??), 19-Июн-26, 08:41
	Похоже на то. Подзадолбали на самом деле подобные потуги. Как вспомнишь soap, так в холодный пот бросает. Если вам http нужен просто как транспорт, ну возьмите tcp. Зачем издеваться...
	Ответить | Правка | Наверх | Cообщить модератору

119. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
Сообщение от Олег (??), 19-Июн-26, 08:51
Пипец тупая идея. Про отправку кучи данных для запроса - это не так делается. Любой кто делал restful-сервис знает как это делается. Про прокси чушь какая-то. Если это прямой прокси, то в наше время это почти всегда CONNECT - какие нах#р логи? Если это обратный прокси, то это сторона сервиса, которым пользуемся и там наши данные и так видят.
Ответить | Правка | Наверх | Cообщить модератору

125. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
Сообщение от rvs2016 (ok), 19-Июн-26, 10:16
Блин. Не усмотрел, что в этом браузере я не залогинен на опеннете и сообщение моё ушло в него от Анонима. Повторяю его тут, а анонимное сообщение "1.124, Аноним (124), 10:13, 19/06/2026" модераторы пусть завалят. Ниже идёт повтор сообщения. А абзацы, начиная с этого и выше, модераторы в нём тогда тоже пусть привалят. Лучше наваяли бы какой-нибудь там RFC с описанием прямых (именно прямых, а не через промежуточные сервера там всякия) соединений между браузерами посредством запуска в них tcp-серверов (какими-нибудь там командами JavaScript, например, ну в смысле javascript в одном браузере запускает tcp-сервер, а javascript другого браузера к нему потом подключается, можно и на обоих сторонах tcp-серверы включить, если надо - в зависимости от задачи). А то на дворе - первый год второй половины второго десятка лет первого века из третьего десятка лет третьей же десятки веков, а программисты до сих пор не могут соединить между собой напрямую два браузера tcp-соединением для прямого (а не через "потусторонние" сервера) обмена данными между двумя js-скриптами...
Ответить | Правка | Наверх | Cообщить модератору

127. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
Сообщение от Аноним (127), 19-Июн-26, 14:53
Вместо того чтобы тупо унифицировать все запросы и позволить отправлять тело запроса с любым методом, что только упростит кодовую базу. Нет, мы хотим усложнить, упрощение для лохов. А тут получается что надо еще и альтернативу для HEAD делать.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема