Не вижу противоречий.

Colonel 23.12.2020 06:12

Написанная вами информация мне хорошо известна, но все равно спасибо, пригодится людям, читающим форум.

Я же не вижу противоречий, и слово "get-параметры" применил условно, разве что не поставив кавычки.

Я это и имел в виду, что хотя get и post, взаимоисключающие методы, тем не менее, "народный термин" get-переменные таки бытует, понимающий под этим конечно же query string, но просплитованный по "=" и "&".

Причём "поверие" это далеко не моё, и не в рунете придуманное.

Наберите в Google "get-parameter" и получите пучок таких автоответов.

GET parameters (also called URL parameters) are used when a client, such as a browser, requests a particular resource from a web server using the HTTP protocol.

И я помню со времён Perl что именно в такой формулировке это было более популярным.

Я предполагаю что именно подобные "негласные умозаключения" + тот факт, что <form method=get> оперирует со всеми <input> именно через query string -- стало неявным побуждением склеивать/взаимоисключать url-параметры и post-параметры из тела запроса при post методе. Что на самом деле вещи разной природы.

О вкусовщине, что считать нужным или ненужным, это уже другой вопрос.

Кейс, например такой, что есть часть параметров которые хочется запретить получать именно post-ом, например дабы лишний раз никто не прислал это ссылкой, или вставкой псевдокартинки на стороннем ресурсе, тогда как форму с post уже тривиальной ссылкой (без js) не вставишь, да и обрабатывается она браузером иначе: рефреш без подтверждения не пройдет, и т.п.

Сейчас речь не о CSRF особо, борьба с этим имеет простые и известные методы, типа добавка токена.

Тут речь об удобстве. Если хочется сделать некую init-конфигурацию и определить ряд доп правил валидации входящих, ожидаемых параметров, среди которых и http-метод, то приходится проделать много возни чтобы все нормализовать все, провалидировать и собрать красивый многовложенный хеш, где http-запрос уже более красиво разложен на url-параметры и post-переменные, отдельно.

Всякие accept-language, и прочие accept- распарсены на составляющие,

с этим потом удобно и приятно работать, но кажется что вот такая более вкусная предпоготовка данных могла бы иметь место, т.к. кодом на парсере она становится весьма громоздкой.

Если бы Парсер был полноценным http-фреймворком (как его иногда тут называли), именно в плане всех удобств разжевывания запроса.

То никто бы не писал лишний раз свой фреймворк/middleware классы на коде Парсера, в части типовых манипуляций со все ещё "сырым http", а предался только радостям ваяния orm, чего-то там более высокоуровневого.

Я сейчас именно о вкусовщине, т.к. вопрос был, чего вам надо, мне бы вот именно фреймворковости от самого Парсера побольше.

Про разбор всех заголовков на вложенные значения (как у accept-language) я писал выше. Можно б и user-agent уже нативным классом распатронить, все эти регулярки, нормализации выливаются в довольно емкую фазу.

Да и runtime методы/классы может какие то, т.к. сейчас оно из коробки голое, как велосипед, и каждый здравомыслящий городит свою runtime обвязку на try/exeption и чего то там. Как минимум для дебага, более богатого логирования при ловле ошибок, и т.п.

---