LINUX.ORG.RU

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

 , ,


0

2

Как-то так вышло, что писал post/get запросы и особенно не задумывался. Простенькие типы данных передавал get, бинарные post, а тут значит, заявил мне коллега, что get передавать это плохо. Почему плохо, обосновать не смог. В моем случае речь идет об очень простых типах get http://someserver.ru/logger.php?device_id=666&status=1

Типа устройство 666 живо. Все. Может быть есть подводные камни которых я не знаю?


Ответ на: комментарий от RazrFalcon

+100500

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

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

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

deep-purple ★★★★★ ()

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

RTFM

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

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

ivn86 ()

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

anonymous ()

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

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

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

anonymous ()
Ответ на: комментарий от deep-purple

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

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

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

xpahos ★★★★★ ()

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

da17 ()

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

logicoop1 ()
Ответ на: комментарий от logicoop1

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

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

ivn86 ()
Ответ на: комментарий от EXL

Напомните, для чего 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" ...>

beastie ★★★★★ ()
Ответ на: комментарий от EXL

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

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

arthas ()

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

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

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

xpahos ★★★★★ ()
Ответ на: комментарий от Eddy_Em

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

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

delightfish ()
Ответ на: комментарий от delightfish

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

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

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

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

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

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

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

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

delightfish ()

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

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

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

zudwa ()
Ответ на: комментарий от da17

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 всё-таки есть таймауты, хотя сама идеология долго что-то там вычислять это зло.

anonymous ()
Ответ на: комментарий от anonymous

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

da17 ()