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

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

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

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

4. Сообщение от Аноним (4), 18-Июн-26, 10:03	+4 +/–
А кто вам запрещает в GET вставлять ненулевое тело? HTTP это не запрещает, да и я так делал и делаю
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10, #16, #20, #34, #36, #70, #131

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

34. Сообщение от 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-запросах не приходит, например...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

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

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

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

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

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

40. Сообщение от qrKot (?), 18-Июн-26, 11:55	+3 +/–
Где нарушает-то? Читаем спеку: '''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ообщить модератору
Родитель: #33

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

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

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

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

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

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

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

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

51. Сообщение от qrKot (?), 18-Июн-26, 12:27	+2 +/–
>> Никто и ничто не мешает передавать параметры запроса точно также как в посте - через тело гета. Спека это разрешает. Никто и ничто не мешает реверс-прокси, ингрессам, бордер-гейтвеям и т.д. игнорировать тело запроса при передаче. Спека это разрешает. >> Единственный "бонус" от появления 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 не имеет право изменить что-то в процессинге запроса, нахрена его вообще передавать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #92

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

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

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

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

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

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

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

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

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

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

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

63. Сообщение от Assador (ok), 18-Июн-26, 13:12	+5 +/–
Надо предложить 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, #83, #133

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

92. Сообщение от Аноним (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ообщить модератору
Родитель: #51

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

130. Сообщение от Аноним (130), 20-Июн-26, 08:26	+2 +/–
Я не знаю кому там кто и что запрещает и зачем множат сущности, но на работе по приколу здоровенный сервис целиком на методах DELETE написал, и никто претензий не предъявлял, все довольны
Ответить | Правка | Наверх | Cообщить модератору

131. Сообщение от Аноним (131), 20-Июн-26, 09:24	+/–
>да и я так делал и делаю 1. Зачем? 2. Отсутствие формального запрета не предполагает формальное разрешение. 3. Вы, очевидно, никогда не занимались безопасностью и эксплуатацией информационных систем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

132. Сообщение от DindiDag (?), 20-Июн-26, 17:27	+/–
Ну не депрекейт, а обсолет, справедливости ради))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

133. Сообщение от DindiDag (?), 20-Июн-26, 17:31	+/–
Отличный стёб, спасибо!!! Есть ещё инженеры с чувством юмора))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

134. Сообщение от Аноним (134), 21-Июн-26, 04:14	–1 +/–
Так называемым "стандартом" поддерживается только GET и POST. Забавно если и правда можно переназначить это дело на PUT и сделать страничку с поддержкой WebDAV вообще без JS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120

135. Сообщение от Аноним (134), 21-Июн-26, 04:21	+/–
Даже лучше. Судя по описанию - это буквально POST, который сам тело не отдаёт, но возвращает ссылку на сгенерированный ответ по твоему запросу, который уже потом можно GET. Нахер оно нужно - вопрос открытый.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

136. Сообщение от Аноним (134), 21-Июн-26, 04:30	+/–
Это если ты напрямую свой сервер выставишь к клиенту и не будешь сидеть за http-проксями, типа того же cloudflare чтобы лутать халявный CDN взамен полного контроля и аудита от клауды за всем траффиком, который идёт к твоему сайту и твоим юзерам. Там уже могут возникнуть различия, т.к. спека настоятельно рекомендует НЕ совать тело в GET. Правда, нафига нужен был QUERY, если это же самое реализуется отправкой запроса через POST, сервер возвращает тебе редирект на страницу с uuid вместо читабельного запроса в uri, и затем CDN может сколько угодно GET-ать эту статичную страницу, пока у неё не истечёт срок годности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

137. Сообщение от Аноним (134), 21-Июн-26, 04:37	+/–
POST по определению не кешируется, поэтому для вебманке придумали специально обозванный POST, который не сам отвечает запрошенным контентом который нельзя кешировать, а заставляет бекенд сгенерировать ссылку на контент и вернуть её, чтобы клиент уже делал GET сколько влезет. Короче "для тупых" объяснили, как пользоваться HTTP. Правда я уже чую тут несколько уязвимостей с такой схемой для узнавания того, что внешний наблюдатель знать не должен был, но в голову лезет только анализ по таймингу и поведению трафика.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

138. Сообщение от Аноним (138), 21-Июн-26, 13:37	+/–
С браузерами еще как-то можно организоваться, а вот веб серверы https://github.com/nginx/nginx/blob/master/src/http/ngx_http... надо будет чинить, из-за этого пойдут срачи о том делать ли поддерживаемым или писать по новому.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

139. Сообщение от Аноним (138), 21-Июн-26, 13:51	+/–
Ха-ха-ха, в программировании принята такая штука как code review и там довольно часто (а я работал во многих компаниях) звучат интересные интерпретации той или иной нормы. К счастью я от этого ушел года 4 назад когда сам стал все проверять, но память этого всего жива. Например мне один разработчик рассказывал как надо все конвертации увести в сервисы, другой говорил тащить в контроллеры и ты сидишь ищешь цитаты из Фаулера, чтобы им из книжки привести что где-то надо в контроллере, где-то в сервисе. Или например какому-то чудаку приспичит внезапно всё переписать на gRPC, потому что быстрее ж, но далее приходит заказчик и говорит что он будет отсылать какую-то фигню в данных и тут начинают городить костыли. Далее кому-то надо нарисовать пресловутый RESTful и рассказать что для поиска только GET и двумерные массивы тоже рисуй в GET и это блин тимлид, сначала пытаешься доказать что это не нормально, но далее устаешь от этого и сам уходишь. В общем долбанариумов после курсов на квадратный метр в ИТ много и тех кто просто хочет спокойно работать и не сраться часто меньше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

140. Сообщение от torbasow (ok), 21-Июн-26, 21:16	+/–
А мне что делать? Комп я обновлял в декабре, расширений у меня меньше десятка и все нужные, а вкладка сейчас открыта ровно одна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

141. Сообщение от Джон Титор (ok), 22-Июн-26, 19:40	+/–
Ну допустим будет ipc между браузерами. Зачем? Между вкладками мало?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125

142. Сообщение от Аноним (142), 24-Июн-26, 19:54	+/–
> Безопасник всё правильно сказал Ага, и скорее всего попутно отключил IPv6, забанил ICMP (MTU discovery же нам нафиг ненужон), вообще оставил только TCP на порту 443 и купил себе фоторамку с изображением кита внутри грузового контейнера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

143. Сообщение от penetrator (?), 30-Июн-26, 09:50	+/–
>>> VERB должен поддерживаться браузером, с полной реализацией связанной с методом спецификации > Открываем дебажную консольку браузера, пишем там: > fetch('http://127.0.0.1:8080', {method: 'QUERY'}).then(resp => { console.log(resp)}); > Видим ответ. ЧЯДНТ? это называется пользовательский VERB, браузер не устанавливает на него ограничений, но сразу задает, что все пользовательские являются non-simple (т.е. при CORS будет preflight), и для них можно использовать любой Content-Type т.е. запросы fetch('http://127.0.0.1:8080', {method: 'QUERY'}) fetch('http://127.0.0.1:8080', {method: 'ZALUPA'}) fetch('http://127.0.0.1:8080', {method: 'NA'}) fetch('http://127.0.0.1:8080', {method: 'VOROTNIK'}) с точки зрения спецификации не отличаются
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

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

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