Всю жизнь передавал данные cgi скриптам методом get. А тут говорят так нельзя.

Почему плохо, обосновать не смог.

В биореактор его.

Ты запросом получаешь логи для девайса 666 со статусом 1?

+100500

ТС: гет кешируется, пост нет, гет для «чтения», пост для «записи».

Ну и на сладкое:

Допустим, ты залогинен в какой-то админке. Я такой пишу тебе, «прива чел! смори какие у тёлки буфера!». И... всё, ты попал ну или не ты, а тот, кого удалило (посмотри что в ссылке).

Почему плохо, обосновать не смог.

RTFM

Метод GET запрашивает представление ресурса. Запросы с использованием этого метода могут только извлекать данные.

POST используется для отправки сущностей к определённому ресурсу. Часто вызывает изменение состояния или какие-то побочные эффекты на сервере.

У запросов есть семантика: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods - ткни ею коллеге (И себе) в лицо. Ещё есть всякие ограничения на длину запроса, корявые фреймворки и т.д., но это - не похоже на тот случай. Может быть он на столько некомпетентен, что считает «невидимость» аргументов запроса каким-то шифрованием.

Почему плохо, обосновать не смог

Ну и в чем вопрос тогда, лол

Помню один сверхразум тоже изменял состояние через get, а именно удалял данные.

Была это самодельная cms/crm для одной компании, всё было хорошо, она работала, любовно наполнялась данными. Ровно до того момента когда не пришло время выкатывать в её в дикие интенреты, и после прохождения первого же поискового бота все данные из этой чудо-юды были дропнуты.

Продолжай дальше) без таких как ты будет очень скучно)))

ТС: гет кешируется, пост нет, гет для «чтения», пост для «записи».

Нет. GET/POST различаются не кэшированием, для кэширования в RFC есть отдельные разделы.

Все методы различаются по идемпотентности. GET - идемпотентен, POST - нет.

Может быть есть подводные камни которых я не знаю?

Читай про SQL инъекции, например. Если подставить специальные SQL символы типа % — ; * и т.п. можно подобрать такие строки, которые будучи добавлены через GET запросы в другие строки приведут к формированию запросов вида SELECT ... OR 1=1; DROP TABLE *;

К POST запросам это тоже относится, впрочем. Но их подобрать сложнее — нужен хотя бы curl, wget и т.п.

Так что все получаемые переменные через GET/POST запросы нужно фильтровать на наличие спец. символов.

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

Ну и по смыслу у них семантика немного разная, ага.

Ага. Забавно в логах сайта-однострочника со статическим хтмл наблюдать, как кто-то долбится по путям типичных для wordpress и прочего похапе, с get строками.

Нет, девайс 666 дергает скрипт и в базу падают логи (ну там еще токен идет, что бы злыдни просто так не дергали)

Типа устройство 666 живо

Это вопрос или утверждение?

Устройство с id 666 периодически обращается к серверу get запросом и передает свое состояние. Тут да. Устройство 666 живо, о чем и сигнализирует передавая параметр status со значением 1.

Тогда «сверхразум» - это ты, потому что ложкой чистишь обувь, а щёткой кушаешь суп.

Что будет, если два раза подряд дёрнуть?

Все методы различаются по идемпотентности. GET - идемпотентен, POST - нет.

То есть ты не можешь изменить отвер сервера в GET?

Возбудимся. Да ничего не будет, в БД есть одна запись о последнем состоянии.

Я думаю так: get и post только для стандарта. Стандарт для того чтобы разраб не изучал каждый сервак в отдельности. В остальном разницы нет. Технически

Я думаю так: get и post только для стандарта.

Двери и окна только для стандарта, можно обходиться окнами, через них можно не только смотреть, но и ходить.

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

все данные из этой чудо-юды были дропнуты.

Надеюсь, к тому времени админы чудо-юды получили ачивку «уже делаем бэкапы»?

Проорал) Ну а если бы она через post удаляла)

Ну зато какой experience

ну давным давно в пых-пыхе переменные GET автоматом преобраз. в локальные переменные. И стояла такая настройка по дефоулту.

Напомните, для чего PUT и можно ли в чистом HTML сделать форму, которая PUT, а не GET/POST отправляет?

Ну можно, только если управлять надо добавить токены наверное типа http://host/netcmd.php?token=asdklfhasdfokjhasdofhasiodfhasfhasdifu&device_id=666&status=1 иначе тебе просто ссылку пришлют тык на которую приведёт к чему угодно. Гетом обычно читают чаще

Напомните, для чего PUT

В общем случае как-то так:

• GET. Retrieve information.
• POST. Request that the resource at the URI do something with the provided entity.
• PUT. Store an entity at a URI.
• PATCH. Update only the specified fields of an entity at a URI.
• DELETE. Request that a resource be removed; however, the resource does not have to be removed immediately.

можно ли в чистом HTML сделать форму, которая PUT, а не GET/POST отправляет?

Запросто. <form method="PUT" ...>

можно ли в чистом HTML сделать форму, которая PUT, а не GET/POST отправляет?

Нет, формы в HTML поддерживают только методы GET и POST, попытка использования любого другого метода приведет к неявной трактовке его как GET

Чушь полная! Передавай и дальше.

Но post/get несут определенные накладные расходы + они не асинхронны. Поэтому рекомендую от этих динозавриных методов отказаться в пользу вебсокетов.

Я полагал вебсокеты это для браузер-сервер, а у меня межмашинный интерфейс.

Тогда на кой черт там вообще веб? Если у тебя интерфейс межмашинный, так и используй UNIX-сокеты!!!

ого! А ты чего это восстал из анонимусов? корзину печенья и бочку варенья пообещали?

через прокси они не работают

Тогда вебсокеты. Они работают.

через прокси вебсокеты не работают

Он более или менее подходит для случае передачи менее 127 байт. Решение использовать 7 битное поле для размера пейлоада и 127 для расширенного пейлоада несколько странное. Вообще весь протокол выглядит как один большой костыль. Лучше все же gRPC.

Если прокся поддерживает 101, то работает.

Да шо ты говоришь!

Поэтому рекомендую от этих динозавриных методов отказаться в пользу вебсокетов.

Эдик, какая муха тебя укусила? Какие вебсокеты, по моему именно ты мне доказывал их убогость и силу хттп/cgi?

mqtt тебе надо, его любая козявка умеет.

Я это доказывал, когда вебсокеты были дряхлыми и только-только начинали развиваться. Сейчас же я не вижу смысла писать веб-приложения на CGI. Вебсокеты имеют значительные преимущества! И ради псевдоасинхронности не нужно 50 раз в секунду долбить сервер запросами — достаточно просто ждать, что там из вебсокета приплывет...

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

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

С того момента ничего не изменилось, но ладно.

Сейчас же я не вижу смысла писать веб-приложения на CGI. Вебсокеты имеют значительные преимущества! И ради псевдоасинхронности не нужно 50 раз в секунду долбить сервер запросами — достаточно просто ждать, что там из вебсокета приплывет...

Ну это правильно. Поздравляю.

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

Ну они достаточно избыточные, если ненужен веб. Но в целом да. Если на таком базовом уровне вполне, правда запаришься их запиливать.

так можно делать, но не принято с т.з. дизайна http restful api

в котором GET device_id=666&status=1 и device_id=666&status=0 это запрос у API объектов с разными статусами (0 или 1)

а для изменения состояния используется PATCH или PUT

Используй обычные tcp-сокеты и socks-прокси. Внезапно работает.

websocketd гитхаб

пример

скрипт, почти что CGI-шный, или из REPL

#!/bin/bash

# Count from 1 to 10 with a sleep
for ((COUNT = 1; COUNT <= 10; COUNT++)); do
  echo $COUNT
  sleep 0.5
done

запускаешь приблуду

$ websocketd --port=8080 my-program

читаешь выхлоп скрипта через вебсокеты

var ws = new WebSocket('ws://localhost:8080/');

ws.onmessage = function(event) {
  console.log('Count is: ' + event.data);
};

и всё: у тебя похожий на CGI скрипт, только:

1. асинхронный

2. передача аргументов проще

3. прикрутить выхлоп постоянно работающего скрипта в виде демона — проще. в CGI всё-таки есть таймауты, хотя сама идеология долго что-то там вычислять это зло.

в одном запросе — зло, разбивать надо на несколько

пример

This examples directory shows how websocketd can also serve CGI scripts via HTTP.

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

я чет сразу не вкурил, у меня нет браузера с js, у меня есть устройство на котором есть по написанное на си++, которое шлет гет запросы php скрипту на сервере.

а вот например многопоточный счётчик на C++, который шлёт запросы через вебсокеты

а websocketd уже их пересылает в браузер, который через js читает их асинхронно