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

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

Сообщения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	24. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+1 +/–
	Сообщение от 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ообщить модератору

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

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

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

	35. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от 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ообщить модератору

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

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

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

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

	40. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от 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ообщить модератору

	44. Скрыто модератором	+/–
	Сообщение от Аноним (42), 18-Июн-26, 12:00
	ты бы и собаку...
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

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

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

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

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

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

	27. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от LaunchWiskey (ok), 18-Июн-26, 11:03
	Раньше было лучше!
	Ответить | Правка | Наверх | Cообщить модератору

14. Скрыто модератором	–2 +/–
Сообщение от Аноним (16), 18-Июн-26, 10:42
Старые W3C nepдyны никак не успокоятся со своим устаревшим, убогим, избыточным HTTP! Всё изображают активность стюардессы. Есть JSON-RPC - намного более удобный и гибкий протокол, но клоуны после недельных курсов будут с завидной настырностью лепить свои __овноподелия на REST.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

	51. "Стандартизирован HTTP-метод QUERY, комбинирующий возможности..."	+/–
	Сообщение от 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ообщить модератору

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

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

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

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