Обработка post запроса при помощи HTTP сервера, Pico RP2040 и W5500

Question

Здравствуйте, я использую pico rp2040 и wiznet w5500. Для взаимодействия с w5500 использую библиотеку wiznet c github. Из этой библиотеки я беру пример http сервера и пытаюсь обработать post запрос в httpUtil.c. Post запросом в моем проекте является получение файла и последующее его сохранение на sd-карту. Результат Post запроса я вывожу через printf(p_http_request->URI), для небольших файлов районе ста байт работает стабильно, для 300-600 байт не стабильно, выводит через раз, для больших файлов(больше килобайта ничего не выводит в теле запроса). uint8_t http_post_cgi_handler(uint8_t * uri_name, st_http_request * p_http_request, uint8_t * buf, uint32_t * file_len) { uint8_t ret = HTTP_OK; uint16_t len = 0; uint8_t val = 0; if(strcmp((const char *)uri_name, "example.cgi") == 0) { // To do val = 1; len = sprintf((char *)buf, "%d", val); printf(p_http_request->URI); } else { // CGI file not found ret = HTTP_FAILED; } if(ret) *file_len = len; return ret; }

Eugeny · Answer

Это подпрограмма, которая выводит результат. А где то, что получает данные? Библиотека веб-сервера, которую вы используете, поддердживает HTTP POST?

Eugeny · Answer

Что показывает, если включить _HTTPSERVER_DEBUG_? В принципе система-то простая, без дополнительной информации мыслей по возможной причине заявленной проблемы нет.

wolfhess · Answer

На первом фото отправлен маленький файл(387 байт) - его тело полностью выведено. Это обычные текстовые единицы, не бинарные. На втором файл размером 2.13 КБ, его тело не выведено и буфер приема сокета переполнен, как я понимаю. Если отправить 8 раз такой файл(максимальное число соединений, которое задается в главной функции), то все сокеты зависают намертво и даже не выполнить обычный GET запрос. 1111658×923 20.7 KB 222221157×653 20.3 KB

Eugeny · Answer

Здесь почему-то нет никакого диагностического вывода. Поставтьте его туда и сюда, чтобы определить, исполняется ли это все, и с каким статусом завершается. Не думаю, что “буфер переполняется”, это базовая функция, которая должна быть отточена до блеска. Скорее всего, проблема где-то в другом месте.

wolfhess · Answer

Добавил диагностический вывод. int8_t listen(uint8_t sn) { CHECK_SOCKNUM(); CHECK_SOCKMODE(Sn_MR_TCP); CHECK_SOCKINIT(); setSn_CR(sn,Sn_CR_LISTEN); while(getSn_CR(sn)){printf("
listen: %i
", sn);}; while(getSn_SR(sn) != SOCK_LISTEN) { printf("
close: %i
", sn); close(sn); return SOCKERR_SOCKCLOSED; } return SOCK_OK; } case SOCK_INIT: listen(s); printf("
SOCK_INIT:%i
",s); break; case SOCK_LISTEN: printf("
SOCK_LISTEN:%i
",s); break; default : printf("
default:%i
",s); break; На первой картинке результат до попытки отправлять большие файлы. Прослушивает все 8 сокетов. На второй картинке результат после отправки восьми раз больших файлов, все сокеты закрыты, не загружается даже index страница. После отправки большого файла, сокет обрабатывающий его закрывается навсегда. Читал тут на форуме, что если rx буфер заполнен, то tx не может передавать данные. И то, что буферы имеют архитектуру кольца и при переполнении уже не могут очиститься.

Eugeny · Answer

wolfhess: Читал тут на форуме, что если rx буфер заполнен, то tx не может передавать данные. И то, что буферы имеют архитектуру кольца и при переполнении уже не могут очиститься. Это что-то новенькое. По идее, такого не должно быть. Потому, что тогда это конкретный баг. Скорее всего, кто-то что-то неправильно запрограммировал. wolfhess: После отправки большого файла, сокет обрабатывающий его закрывается навсегда. Такого быть не должно. Где-то в логике проблема. Надо отследить весь процесс по дебаг выводам (в том числе перехода от одного состояния в другое), и посмотреть, почему сокет не переоткрывается и не переключается в режим LISTEN.