nginx fastcgi POST/GET/PUT/DELETE

А так

location /path  {
  if ($request_method = GET ) {
    fastcgi_pass address:port;
  }

  if ($request_method = POST )
  ...
}

опа, как все просто) спасибо

Better:

map $request_method $backend {
    default address1:port1;
    POST    address2:port2;
}

server {
# ...
    location / {
        fastcgi_pass $backend;
    }
}

Не проверял, но должно работать.

Действительно, есть же map, туплю.
quest, лучше использоваться вариант beastie.

спасибо!

а в этом варианте что-то типа break в блоке if не нужно?

Эм, break для чего? break идеологически должен прерывать что-то, здесь все же не свитчинг/цикл/etc, а перечисление линейных условий. Опять же все зависит от целей, которые вы преследуете. Поясню на примере кода выше:

location /path  {
  ... // инструкции отрабатывают
  if ($request_method = GET ) {
    ... // инструкции отрабатывают если метод GET
  }
  ... // инструкции отрабатывают
}

Спасибо, я к тому что обычно все это выглядит типа:

fastcgi_pass   127.0.0.1:9000;
fastcgi_index  index.php;
fastcgi_param  SCRIPT_FILENAME  $document_root/$fastcgi_script_name;

fastcgi_buffers 8 8K;
include fastcgi_params;
access_log off;

и тут не видно какой-то конкретной команды уводящей куда-то поток выполнения и не возвращающей его, если поставить return 200 то лично у меня возникает подозрение не сломает ли это вызов fastcgi. вообщем нужно попробовать. Вариант с map хорош, но это то-же пригодится

К теме http://websocketd.com/

Никому не сдалось это поделие в продакшне. Школота, такая как и ты, пользуется подобными штуками. А нормальные дяди юзают в продакшне сишку.

Иди крути ноду, а это поделие оставь другим дядькам, всеравно ты не шаришь в чем ее плюсы, а в чем минусы.

ты не поверишь но я 1) не школота 2) писал на сишке websocket демоны 3) вижу потенциал в websocketd как в отдельном инструменте на котором можно обкатать прототипы как минимум

писал на сишке

Если ты писал на сишке, то должен понимать, что модель форкающихся процессов может быть не поднять-не встать затратной. А чтобы было уж совсем чики-пуки, то можно выкинуть вызовы форка и пайпов ИЛИ сделать как тру-папка по модели fastcgi (один процесс всегда запущен и ничто никуда не форкается).

Увы, ты это все пропустил. Иначе бы понял что можно, а что нельзя сделать с websocketd.

ты будешь удивлен но я знаю что такое CGI почему он запускается именно в дорогих процессах а не потоках, а также что такое FastCGI и воркеры на основе тредов в nginx. и по приведенной тобой ссылке я говорю об этом же. по крайней мере websocketd использует epoll, а не select/poll и есть шанс на его развитие в сторону потоков и спешел протокола типа FastCGI ибо это логично

что такое пул потоков я то-же знаю