BASH CURL: Не закрывайте соединение между запросами при последовательном запуске

Question

Я пытаюсь написать команду BASH, которая использует CURL для отправки запроса GET на две разные веб-страницы, но использует то же соединение. Для меня это похоже на отправку запроса GET на страницу входа в систему для аутентификации на сервере, а затем второй запрос имитирует автоматическое перенаправление на главную страницу, которая произошла в веб-браузере (через meta refresh tag). Мне нужно связать запросы, потому что содержимое домашней страницы (сгенерированной сервером) будет отличаться для гостевого пользователя, чем аутентифицированный пользователь.

Я попробовал эту команду первой, основываясь на рекомендации от SOF post (предположим, что переменные $IP и $PORT уже определились с действительными значениями):

curl -u user:pass ${IP}:${PORT}/login.php && curl ${IP}:${PORT}/index.php 

Однако, я всегда получаю что-то вроде этого происходит между концом первый GET и начало второго:

* Connection #0 to host 10.0.3.153 left intact 
* Closing connection #0 

Так было ли сообщение SOF неправильно? В любом случае, делая эту команду будет успешно держать соединение открытым между двумя запросами:

curl -u user:pass ${IP}:${PORT}/login.php ${IP}:${PORT}/index.php 

Однако, я действительно предпочел бы решение ближе к бывшей команде, чем вторая команда. Основная причина заключается в том, чтобы отделить вывод с первой страницы по сравнению со второй страницей на два разных выходных файла. Так что я хочу сделать что-то вроде:

curl page1.html > output1 && curl page2.html > output2 

Конечно, мне нужно повторно использовать то же самое соединение, так как содержимое page2.html зависит от меня и делает запрос на page1.html в том же HTTP-сессии.

Я также открыт для решений, которые используют netcat или wget, НО НО PHP!

Answer 1

Выполнение локонов a.html & & локон b.html обязательно использовать два TCP (HTTP) соединения для извлечения данных. Каждая операция завивки - это собственный процесс и откроет свое собственное соединение.

Однако веб-сайт не использует соединение TCP/HTTP для отслеживания информации для входа в систему. Вместо этого какой-то токен помещается в сеанс (обычно с использованием файла cookie), который передается в последующих запросах на сайт. Сайт проверяет этот токен на последующих запросах.

Curl имеет опцию -c, чтобы указать, где куки должны храниться между соединениями

curl -c cookiejar -u user:pass login.php && curl -c cookierjar index.php 

будет ближе. Я говорю ближе, потому что многие сайты не используют аутентификацию на основе http, поддерживаемую опцией -u, но вместо этого используют пользовательские формы, а во-вторых, вызовы предполагают использование cookie (в отличие от встраивания чего-либо в javascript или URL-адрес). Последнее вероятно, но я не буду рассчитывать на первый бит.

Answer 2

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

xidel http://${IP}/login.php --download page1.html -f '"index.php"' --download page2.html 

Или если есть связь с первой страницы на второй, он может непосредственно следовать этой ссылке:

xidel http://${IP}/login.php --download page1.html -f //a --download page2.html 

Однако он не поддерживает аутентификацию HTTP или другие порты, чем 80,8080 и 443 пока (бэкенд будет поддерживать его, но между ними является проверка URL, который отвергает его как недействительный URL)

Answer 3

Согласно curl manual конспект является следующее:

curl [options] [URL...]

Это означает, что вы можете указать несколько URL-адресов друг за другом в одной команде , Curl будет повторно использовать ручку для каждого последующего URL:

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