Почтовый запрос получен на машине, но сервер не распознает его, если источник не является локальным [http, php, post, apache, wireshark]

Я установил на своем компьютере веб-сервер Apache с помощью инструмента XAMPP. Он запускает сценарий PHP, который проверяет запросы POST и сохраняет значения POST в текстовом файле.

<html>
<body>
<?php
$filename = "temperatures.txt";
$current_content = file_get_contents($filename);
if (!empty($_POST))
{
    $temperature = $_POST["temperature"];
    $new_contents = $current_content . $temperature . "\n";
    file_put_contents($filename, $new_contents);
}
else
{
    $new_contents = $current_content . "unknown\n";
    file_put_contents($filename, $new_contents); 
}
?>
</body>
</html>

Я протестировал сценарий, сгенерировав запрос POST с помощью Curl, инструмента командной строки. Я сделал это с локальной машины, на которой работает сервер. Это команда, которую я выполнил:

curl -i -X POST -H 'Content-Type: application/json' -d "temperature=10" https://192.168.88.254/index.php"

Затем у меня также есть шлюз / маршрутизатор IoT в той же сети LAN, который также отправляет запросы HTTP POST. С помощью Wireshark я убедился, что машина принимает пакеты от обоих источников.

Первая запись — от шлюза IoT, вторая — от curl.

Однако сценарий выводит в файл «неизвестное» значение, когда шлюз Интернета вещей был источником.

Кто-нибудь знает, почему Wireshark улавливает значение сообщения от шлюза IoT, а сервер — нет?

temperatures.txt
10
unknown

Результаты в журнале apache

192.168.88.254 - - [12/Mar/2021:11:40:06 +0100] "POST /index.php HTTP/1.1" 200 29 "-" "curl/7.55.1"
192.168.88.1 - - [12/Mar/2021:11:40:25 +0100] "POST /index.php HTTP/1.1" 200 29 "-" "Mikrotik/6.x Fetch"

Согласно руководству Как задать вопрос, которое вам рекомендуется прочитать перед использованием сайта, пожалуйста, не публикуйте изображения вашего кода или данных. Обе эти вещи являются текстом. Вставлять его как графику очень непрактично, так как его нельзя копировать, искать, повторно использовать в ответах и т. Д. Это затрудняет работу тех, кто может захотеть вам помочь. Измените свой вопрос, включив информацию в виде текста, и используйте инструменты форматирования, чтобы представить его красиво, чтобы его могли использовать те, кто хочу вам помочь. Спасибо — person Dirk schedule 12.03.2021

См. также: ВНИМАНИЕ: индекс RubyGems 1.2+ не найден для: RubyGems вернется к устаревшим индексам, что снизит производительность

Какая из записей WireShark взята из запроса cURL, а какая из шлюза? Второй, похоже, пересылает запрос самому себе. — person Dirk schedule 12.03.2021

P.S. Ваш пример файла результатов не содержит ни одного из значений из ваших образцов wirehark. Если вы собираетесь показывать данные, сделайте их последовательными от начала до конца. — person Dirk schedule 12.03.2021

Я обновил свой вопрос, как вы предложили. Первая запись — от curl, вторая — от шлюза Интернета вещей. Вы также правы, что данные были несоответствующими. Случайно перепутал скриншоты. Теперь это правильно — person Dirk schedule 12.03.2021

Спасибо. The first entry is from curl, second one from wireshark … вы имеете в виду, что вторая запись с устройства IoT? Я обновил ваш вопрос, включив в него эту информацию, предполагая, что это та формулировка, которую вы имели в виду. — person Dirk schedule 12.03.2021

Во втором запросе я заметил странную вещь: источник и место назначения — 127.0.0.1 (т.е. локальный шлейф). Вроде шлюз сам себе запрос отправляет ?? Перенаправляется ли он позже на IP-адрес сервера apache? — person Dirk schedule 12.03.2021

Прошу прощения за все запутанное. Первый на самом деле от шлюза IoT, источник (192.168.88.1), а пункт назначения — мой компьютер (192.168.88.254). Второй запрос — это обратная петля, просто чтобы проверить скрипт. С помощью обратной связи данные записи регистрируются, а шлюз в качестве источника не — person Dirk schedule 12.03.2021

Хорошо, я вижу. В этом больше смысла. Итак, наконец, вопрос находится в пригодном для использования состоянии. Должен сказать, только по этой информации я не могу понять, почему у вас возникла эта проблема. Все выглядит хорошо, исходя из того, что показано, поэтому я думаю, что нам нужно больше деталей. Журналы Apache что-нибудь говорят об этом? Я знаю, что они обычно не записывают значения POST, но они записывают, какой тип запроса поступил. Единственное, что я могу придумать, — это показать журналы (или, возможно, другие биты, которые мы не видим в вашем снимки экрана wirehark) заключается в том, что шлюз не отправляет HTTP POST — возможно, он отправляет GET или что-то еще — person Dirk schedule 12.03.2021

См. также: Что не так с управляющими символами в инструменте командной строки PHPUnit?

Я просто добавил к вопросу логи apache. Ничего странного здесь не вижу. — person Dirk schedule 12.03.2021

Спасибо. Согласен, ничего странного в этом нет. Я думаю, что следующим шагом может быть заставить Apache выгружать данные POST, чтобы вы могли видеть, правильно ли данные, которые вы видите в Wireshark, точно принимаются сервером — это до того, как они достигнут PHP, поэтому это еще одна ссылка в цепь. Нам нужно точно установить, где данные не могут быть получены (или, по крайней мере, не могут быть поняты как данные POST). stackoverflow.com/ questions / 989967 / могут помочь вам это настроить. — person Dirk schedule 12.03.2021

Post Views: 95