А что мешает использовать POST, кроме религии?

чьерт, хотел написать "религия"

Так его и используют. Сводя смысл от глаголов к нулю

семантика

Так вам "шашечки" или ехать надо?

Так мы безусловно лишаемся кеширования

Когда стандарт разрабатывался, не предполагалось, что кто-то будет запрашивать по GET с параметрами со сложной структурой и объёмом до нескольких килобайт. Мы сами себе стреляем в ноги

Ну дык. Есть RFC, есть вендоры которые ему следуют. Я вообще очкую выходить за рамки какой либо спеки, что бы потом больно не было в будущем в случае чего.

Нет. Ноги нам отстрелил бернерс-ли, не подумав о том, во что и как выльется использование http

Или мы используем http там, где надо было использовать что-то другое

Иногда - да. Но не всегда Если есть тонкий клиент (браузер) и куча фильтров, то что ещё можно использовать вместо http?

web-gRPC :D WS Свой протокол на WS POST запросы

оно же все хттп

Ws/rpc - что-то новенькое. Я от длинных урлов страдал в 08-м году Post - это как раз следствие того, что изначально http был не до конца продуман

Существуют ли вообще в разработке вещи продуманные до конца? Когда он создавался, это было совершено новая идея и им было не до таких мелочей как разрешить тело у GET.

так, для разнообразия «эволюция» http протокола)) https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP

а щас появились http2 и http3 и они лучше продуманы?

Нет (не существует). Но это не отменяет того, что я выше писал

Время покажет

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

Но, кстати, продумать то, что get может иметь кучу фильтров - кажется можно было

Если уж с таких позиций разбирать. Если бы они с этим угадали, боль была бы просто в другом. Поскольку идеального не существует, как бы близко они к нему не были, косяк бы нашелся и субъективно воспринимался как существенный.

И за одно какой-нибудь язык запросов встроить в HTTP?)

А давай подумаем, что воспринималось бы тогда как большая проблема

Бардак с хедерами

В теории если так нужен get запрос для кэширования, то фильтры ввиде json-а можно перегонять в url friendly кодировку, например base64, а потом уже на сервере разбирать, но наверное будет медленно работать

Ну вот с этим бы и мучались. Но зато имели бы тельце в get Для кого-то жизнь была бы чуть-чуть проще

И это проходили. Пока не наткнулись на ограничение длины url в ie (давно дело было)

Там вроде 10к символов?

2,048 characters, нагуглил

Ну сейчас он уже мертвец Сейчас таких ограничений нет?

Честно - не помню. Но для нас именно оно стало стопором

Не знаю, сейчас для меня это не актуально

Есть. Причем цифры разные везде. CDN нормально обрабатывают до 8-16 тысяч символов в адресе. Браузеры современные от 10 тысяч до 64 тысячи в среднем.

Если ты спрашиваешь в рамках дискуссии которая выше, то нет. http2 и http3 фактически не меняют структуру и семантику http-сообщения, она по сути едина для http1/2/3. Http2 и http3 ориентированы на такие вещи как сжатие заголовков, мультиплексирование соединения, server push, блокировка HOL, более быстрое соединение (0-RTT) и т.д. и т.п. Иными словами, затрагиваются вопросы внутренней реализации протокола, по факту 99% прикладных программистов могут не заморачиваться и делать все по старинке. А вообще. Http2 не оправдал ожиданий, как и теперь от http3 не ждут что то революционного. Просто эволюционное улучшение.

> Http2 не оправдал ожиданий какие были ожидания? почему не оправдал? чьи это были ожидания?

а что от него ждали?

Вверху ответил