Блог

Главная - Вопросы по программированию - Может загрузить файл с помощью Curl 7.29.0, но не получится при 7.61.1

Может загрузить файл с помощью Curl 7.29.0, но не получится при 7.61.1

#curl #lighttpd

Вопрос:

http-сервер: lighttpd 1.4.45
мой curl cmd:

 RES=`curl -L -s -k -v --request POST 
    --url "https://127.0.0.1/file" 
    --header 'Cache-Control: no-cache' 
    --header 'Accept-Encoding: gzip, deflate, br' 
    --header 'Content-Type: multipart/form-data;' 
    --header 'Connection: keep-alive' 
    --header 'X-Requested-With: XMLHttpRequest' 
    --progress-bar 
    -F "file=@$FileName;type=application/octet-stream;filename=$FileName" --compressed`

7.29.0 его статус равен 200, но 7.61.1 он возвращает 500 (статус: 500 (Внутренняя ошибка сервера))

кто-нибудь знает, чем это отличается ??

Rsp из 7.61.1 является

 * Done waiting for 100-continue
} [5 bytes data]
######################################################################### 100.0%< HTTP/1.1 200 OK
< Cache-Control: no-store, no-cache, must-revalidate, private
< Pragma: no-cache
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Content-Security-Policy: default-src 'self';object-src 'none';connect-src *;style-src 'self';script-src 'self'; img-src 'self' blob:;frame-ancestors 'self';font-src 'self'
< Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
< Content-Type: application/json
< Transfer-Encoding: chunked
< Date: Fri, 20 Aug 2021 14:58:00 GMT
< Server: lighttpd
<
{ [5 bytes data]
######################################################################### 100.0%* Connection #0 to host 127.0.0.1 left intact

status: 500 (Internal Server Error) { "cc": -1 }

это потому, что лайттпд ?? Как я могу это отладить ??

Ответ №1:

Как я могу это отладить ??

Краткий ответ на ваш вопрос состоит в том, чтобы сравнить различия между тем, что было отправлено с curl 7.29.0 и curl 7.61.1. Вы предоставили вывод, curl -v когда использовали 7.61.1, но не предоставили вывод, когда использовали curl 7.29.0.

Кроме того, проверьте журнал ошибок lighttpd, чтобы узнать, сообщает ли lighttpd о причине возврата ошибки 500.

Мета-ответ на ваш вопрос заключается в том, что если вы используете lighttpd 1.4.45, вы используете очень старое программное обеспечение, и большинству людей не стоит тратить время на устранение неполадок. Debian Stretch теперь является старым-старым-стабильным и поставляется с lighttpd 1.4.45 (и lighttpd 1.4.53 в портах с обратным доступом). Debian Buster является старо-стабильным и поставляется с lighttpd 1.4.53 (и lighttpd 1.4.59 в обратных портах buster). Debian Bullseye стабилен и поставляется с lighttpd 1.4.59.

Если вы не можете выполнить обновление, то вы можете попробовать lighttpd 1.4.53 из stretch-backports.

Пример того, сколько лет вашему программному обеспечению: lighttpd добавил 100-продолжайте поддержку в lighttpd 1.4.46, выпущенном в октябре 2017 года, почти 4 года назад. Вы используете lighttpd 1.4.45, выпущенный в январе 2017 года, которому приближается 5 лет!

Комментарии:

1. 7.29 rsp: ######################################### 100.0%< HTTP/1.1 200 OK < Cache-Control: no-store, no-cache, must-revalidate, private < Pragma: no-cache < X-Content-Type-Options: nosniff ............. { [data not shown] ####################### 100.0%* Connection #0 to host 127.0.0.1 left intact то же, что и 7.61.1, но код состояния 200, а не 500, в журнале ошибок он записывает 2021-08-20 15:22:27: (mod_fastcgi.c.2564) FastCGI-stderr: viewer count is empty 2021-08-20 15:22:27: (mod_fastcgi.c.2564) FastCGI-stderr: ------------->Temp Move Failed , что это вызвано FastCGI ??

2. почему в версии 7.29.0 нет этого вопроса (Не удалось выполнить временное перемещение)

3. Эта ошибка в строках журнала lighttpd, которая начинается с «FastCGI-stderr», является сообщением об ошибке из приложения FastCGI-это данные в пакете FCGI_STDERR. lighttpd сообщает эту информацию в журнале ошибок. Проблема где-то в вашем приложении FastCGI, а не в lighttpd. и, вероятно, существует некоторая разница между запросом curl 7.29.0 и запросом curl 7.61.1, поэтому вам следует более внимательно изучить, как разные версии curl отправляют заголовки запросов и тело запроса.

4. Ваш комментарий, который включает в себя «……..» для части заголовков, отправленных 7.29, показано, что вы действительно не понимаете, как предоставить хорошую техническую информацию, когда вас спрашивают о деталях. Я просил о точном наблюдении за выводом curl, а не о вашем анализе, в котором»….. » не было необходимости. Вы не знаете ответа на свой вопрос, поэтому вы не знаете, какую информацию предоставлять и какую информацию опускать. Короче говоря, ваша постоянная неудача заключается в том, что вы продолжаете опускать информацию.

5. Когда я попросил вас посмотреть на вывод curl 7.29, я надеялся, что вы обнаружите разницу в заголовках с одной версией, отправляющей длину содержимого, и другой, отправляющей Кодировку передачи: фрагментированная. Вам еще предстоит поделиться достаточной информацией, чтобы определить это.

Метки: ,