-2

http server: lighttpd 1.4.45
my curl cmd is:

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 it status is 200, but 7.61.1 it return 500 (status: 500 (Internal Server Error))

does anyone know what makes this different ??

Rsp of 7.61.1 is

* 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 }

it is because lighttpd ?? How can I going to debug it ??

Albert.Huang
  • 57
  • 5

1 Answers1

0

How can I going to debug it ??

The short answer to your question is to compare the differences between what was sent with curl 7.29.0 and curl 7.61.1. You provided the output from curl -v when you used 7.61.1, but did not provide the output when you used curl 7.29.0.

Also, check the lighttpd error log to see if lighttpd reports why a 500 error was returned.

The meta answer to your question is that if you're using lighttpd 1.4.45, you are running very old software and it is not worth most people's time to bother troubleshooting. Debian Stretch is now old-old-stable and shipped lighttpd 1.4.45 (and lighttpd 1.4.53 in stretch-backports). Debian Buster is old-stable and ships with lighttpd 1.4.53 (and lighttpd 1.4.59 in buster-backports). Debian Bullseye is stable and ships with lighttpd 1.4.59.

If you are unable to upgrade, then you might try lighttpd 1.4.53 from stretch-backports.

An example of just how old your software is: lighttpd added 100-continue support in lighttpd 1.4.46, released Oct 2017, almost 4 years ago. You're using lighttpd 1.4.45, released Jan 2017, which is approaching 5 years old!

gstrauss
  • 2,091
  • 1
  • 12
  • 16
  • 7.29 rsp is: `######################################### 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 ` same as 7.61.1 but status code is 200 not 500, in error log it write `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` it is cause by FastCGI ?? – Albert.Huang Sep 17 '21 at 09:02
  • why 7.29.0 not have this question (Temp Move Failed) – Albert.Huang Sep 17 '21 at 09:22
  • That error in the lighttpd log lines which starts with "FastCGI-stderr" are error messages from the FastCGI application -- it is data in a FCGI_STDERR packet. lighttpd reports this information in the error log. **The problem is somewhere in your FastCGI application, not lighttpd.** and there is likely some difference between the curl 7.29.0 request and the curl 7.61.1 request, so you should look more closely at how the different versions of curl send the request headers and the request body. – gstrauss Sep 18 '21 at 11:07
  • Your comment which includes "........" for part of the headers sent by 7.29 demonstrates that you really do not understand how to provide good technical information when asked for details. I asked for the precise observation of curl output, not your analysis that "......" wasn't needed. You don't know the answer to your question, so you are not knowledgable about what information to provide and what information to omit. In short, your continuing failure is that you continue to omit information. – gstrauss Sep 18 '21 at 11:10
  • When I asked you to look at the curl 7.29 output, I hoped that you would find that there was a difference in the headers with one version sending Content-Length and the other sending Transfer-Encoding: chunked. You have yet to share sufficient information to determine that. – gstrauss Sep 18 '21 at 11:12
  • There was a bug in lighttpd handling `Transfer-Encoding: chunked` in the request body in lighttpd 1.4.44 - lighttpd 1.4.48. The bug was fixed in lighttpd 1.4.49, released 3 1/2 years ago in Mar 2018. https://redmine.lighttpd.net/issues/2854 – gstrauss Sep 18 '21 at 11:42