Forum Webscript.Ru
Программирование => Perl => Тема начата: Begoo от 28 Июля 2004, 15:41:02
-
Т.е. если я например делаю такой запрос
cmd> POST /cgi-bin/nph-a3.pl HTTP/1.0
cmd> Content-Type: application/x-www-form-urlencoded
cmd> User-Agent: Mozilla/3.0 (compatible)
cmd> Host: 192.168.0.98
cmd> Content-Length: 17
url=url&post=post
Потом в скрипте читаю
read(STDIN, $query, $ENV{\'CONTENT_LENGTH\'});
и пишу
$query=\'\';
while(length($query)<=0) {read(STDIN, $query, 8192);};
Получится ли принять эти данные, если я после POST запроса еще что нить пошлю?
-
Begoo:
Получится ли принять эти данные, если я после POST запроса еще что нить пошлю?
я понимаю что сейчас жарко.. но не мог бы ты сформулировать вопрос покорректнее? ты хочеш свой хедер послать и распарсить его скриптом?
-
в cgi скорее всего нет :)
скрипт грузится после http запроса на сервер,
сервер отсекает параметры запроса и с этими параметрами вызывает скрипт.
в ASAPI (он же мод перл), вполне возможно.
-
NeoNox
Смотри, я соединяюсь с сервером, посылаю ему запрос такого вида
cmd> POST /cgi-bin/nph-a3.pl HTTP/1.0
cmd> Content-Type: application/x-www-form-urlencoded
cmd> User-Agent: Mozilla/3.0 (compatible)
cmd> Host: 192.168.0.98
cmd> Content-Length: 17
Далее идут два enter\'a, и сервер понимает что заголовок окончен.
И передает передачу скрипту. Вот я и хочу узнать, далее это обычное TCP соединение или нет?
Могу ли я как в сокетах, прочитать данные (read(STDIN, $query, 8192)), потом их обработать и послать ответ, далее мой клиент (написанная программа) принимает эти данные, и отвечает опять.... получую ли я эти данные из STDIN?
-
Begoo
Могу ли я как в сокетах, прочитать данные (read(STDIN, $query, 8192)), потом их обработать и послать ответ, далее мой клиент (написанная программа) принимает эти данные, и отвечает опять.... получую ли я эти данные из STDIN?
Получишь, вопрос только от кого (от какого пользователя)?
Billi
в ASAPI (он же мод перл), вполне возможно
А если пользователей более одного? какие переменные будет хранить mod_perl?
Как вариант (если уж так сильно хочется использовать HTTP) дополнительно, передавать между скриптом и пользотелькой программой какой-нибудь уникальный параметр:
1. Первое подключение:
пользователь -> запрос -> скрипт производит обработку генерит ключ -> ответ (с ключем)
2. Последующие подключения:
пользователь -> запрос (с ключем) -> скрипт проверяет ключ, на основе его восстанавливает какие-то параметры требуемые для работы (параметры можно хранить в той же БД) -> ответ
-
Получишь, вопрос только от кого (от какого пользователя)?
хм.. соединение происходит с сервером, и почему он должен будет передать данные скрипту(уже работающему) ???
-
Phoinix
Получишь, вопрос только от кого (от какого пользователя)?
А с кокого перепуга? от этого и получу, соединение то установлено и направлено на этот скрипт.
1. Первое подключение:
пользователь -> запрос -> скрипт производит обработку генерит ключ -> ответ (с ключем)
2. Последующие подключения:
пользователь -> запрос (с ключем) -> скрипт проверяет ключ, на основе его восстанавливает какие-то параметры требуемые для работы (параметры можно хранить в той же БД) -> ответ
Ну это да, можно так сделать, ну опять же задержки.
Просто вообще не понятно как работает сервер: то ли он просто принимает все ожидаемые данные (Content-Length) и потом отправляет их в STDIN, или из STDIN можно читать сколько данных придет и сколько нужно.
Кто может ответить?
-
Begoo Запросы к серверу не связаны друг с другом.
Begoo:
Кто может ответить?
RFC по HTTP популярно отвечает
-
ну если не хочешь ответить то и ладно, а от прочтения еще раз RFC понимания не появиться
-
Begoo
Повторюсь, но все-же процитирую одно замечательную статью:
В момент, когда пользователь видит перед собой страницу и начинает совершать какие-то действия с ней, PHP уже завершил работу! И пользователь взаимодействует не с PHP скриптом, а со своей страницей HTML, которую он получил в браузер. Результатом работы скрипта на PHP в большинстве случаев является обычный текст. Текст HTML страницы. Которая отдается браузеру и показывается им, как обычный HTML.
Полная версия тут - на танке (http://phpfaq.ru/na_tanke)
Надеюсь вопросы типа: "Причем тут браузер?" и "Причем здесь PHP?" - задаваться не будут, ибо насколько я понял из фразы
...а от прочтения еще раз RFC...
Данный документ был прочитан хотя бы раз...
-
спасибо, просто такое ощущение что меня не понимают....
-
Begoo как я много раз повторял своим любимым клиентам, представь себе, что я маленький ребенок и обьясни мне на пальцах.
Отсылая тебя к RFC, я надеялся что ты сможешь обьяснить то что ты не понимаешь. А твое заявление что от понимания действия протокола понимания не появиться является либо скоропалительным, либо тебе лень разбираться с тем что ты делаешь.
-
NeoNox
Вроде человек все понятно объяснил. Я так понял, что его интересует, возможен ли в рамках ОДНОГО соединения диалог между двумя скриптами (один из которых, скрипт-клиент, соединяется с другим, CGI-скриптом, через HTTP), или же это только запрос-ответ, после чего связь рвется и ничего сделать уже нельзя, кроме как посылать новый запрос.
-
Begoo:
Просто вообще не понятно как работает сервер: то ли он просто принимает все ожидаемые данные (Content-Length) и потом отправляет их в STDIN, или из STDIN можно читать сколько данных придет и сколько нужно.
Для каждой задачи в многозадачной среде (т.е. для каждого запущенного скрипта, пусть одного и того же ) формируется своя "окружающая среда", в том числе и свой STDIN и различные переменные окружения.
и если
КшЫуфксрук:
один из которых, скрипт-клиент, соединяется с другим, CGI-скриптом, через HTTP
то ответ на заданный вопрос :"Нет."
-
КшЫуфксрук, диалога между скриптами (в данном случае) не получается напрямую вообще, т.к. общение происходит с сервером. Скрипт запускается на выполнение уже после того, как сервер полностью получил запрос.
2Begoo
> Получится ли принять эти данные, если я после POST запроса еще что нить пошлю?
Сервер возможно и получит дополнительные данные (и только в том случае, если соединение остается открытым), но скрипт их не увидит.
Есть только один способ обойти все это - написать свой скрипт минуя веб-сервер, который будет тебя слушать и отвечать тебе во время сеанса.
-
Athathoth:
Есть только один способ обойти все это - написать свой скрипт минуя веб-сервер, который будет тебя слушать и отвечать тебе во время сеанса.
А вот с этого места поподробнее пожалуйста.
-
NeoNox:
А вот с этого места поподробнее пожалуйста.
Подробное объяснение зависит от решения поставленных задач. :)
Однако сразу оговорюсь, что такое решение на общественном хосте в 99% случаев не прокатит, т.к. придется использовать другой порт, который вероятнее всего у хостера прикрыт...
Сам принцип думаю известен - вешаешь демон в котором открываешь сокет, слушающий определенный порт. Иными словами обычный tcp сервер в котором и http не обязятельно использовать.
Я не настаиваю на таком решении, т.к. у него куча очевидных минусов, однако для решения поставленной проблемы вижу только этот выход...