rejetto forum
Software => HFS ~ HTTP File Server => Bug reports => Topic started by: hanshenrik on January 22, 2022, 01:20:43 AM
-
on hfs 2.3m and "2.4.0 RC6" range requests are broken, if you request bytes out of range, the http request will just hang indefinitely!
this is mostly bad because it breaks wget's ` wget -r -c url` , but it could likely also likely be abused to implement a very efficient DoS attack,
if you have 123.txt containing the exact text "123" (and no newline), doing
> curl 'http://127.0.0.1/123.txt' -H "Range: bytes=3-"
the correct response would be "HTTP 416 Requested Range Not Satisfiable" (because only byte 0-2 inclusive exists),
but that doesn't happen, instead the http connection will just hang indefinitely! hfs never responds, it just keeps the tcp connection alive indefinitely..!
-
after some investigation, turns out that it *does* in fact respond with a bunch of http headers, but no body, and it does keep the tcp connection alive indefinitely.. curl -v log:
$ curl 'http://127.0.0.1/123.txt' -H "Range: bytes=3-" -vv
* STATE: INIT => CONNECT handle 0x80008eff8; line 1789 (connection #-5000)
* Added connection 0. The cache now contains 1 members
* family0 == v4, family1 == v6
* Trying 127.0.0.1:80...
* STATE: CONNECT => CONNECTING handle 0x80008eff8; line 1850 (connection #0)
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
* STATE: CONNECTING => PROTOCONNECT handle 0x80008eff8; line 1980 (connection #0)
* STATE: PROTOCONNECT => DO handle 0x80008eff8; line 2003 (connection #0)
> GET /123.txt HTTP/1.1
> Host: 127.0.0.1
> User-Agent: curl/7.80.0
> Accept: */*
> Range: bytes=3-
>
* STATE: DO => DID handle 0x80008eff8; line 2099 (connection #0)
* STATE: DID => PERFORMING handle 0x80008eff8; line 2218 (connection #0)
* Mark bundle as not supporting multiuse
* HTTP 1.1 or later with persistent connection
< HTTP/1.1 400 Bad Request
< Content-Type: text/plain
< Accept-Ranges: bytes
< Server: HFS 2.3m
< Set-Cookie: HFS_SID_=0.732762209838256; path=/; HttpOnly
< ETag: 491C3211A3BA8673626DDF909E1F59BE
< Last-Modified: Sat, 22 Jan 2022 01:00:01 GMT
< Content-Disposition: filename="123.txt";
* no chunk, no close, no size. Assume close to signal end
<
(here curl just hangs indefinitely)
wget:
$ wget 'http://127.0.0.1/123.txt' -v -c
--2022-01-22 02:25:12-- http://127.0.0.1/123.txt
Connecting to 127.0.0.1:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3 [text/plain]
Saving to: %u2018123.txt%u2019
123.txt 100%[==================================================================================================================================================================>] 3 --.-KB/s in 0s
2022-01-22 02:25:12 (31.1 KB/s) - %u2018123.txt%u2019 saved [3/3]
hans@DESKTOP-2LHJILI ~
$ wget 'http://127.0.0.1/123.txt' -v -c
--2022-01-22 02:25:15-- http://127.0.0.1/123.txt
Connecting to 127.0.0.1:80... connected.
HTTP request sent, awaiting response... 400 Bad Request
2022-01-22 02:25:15 ERROR 400: Bad Request.
- and that 400 breaks wget's -c , which is bad when combined with -r , eg `wget -r -c http://127.0.0.1/ - will only work the first time, the 2nd invocation will be broken with a http bad request error. (because hfs doesn't respond with http 416)
-
sorry for the bug.
i just verified that hfs 3 (next) works correctly with this case
-
good news, but hfs3 is still a long way from being user-friendly, right? any chance of a hfs2 fix?
and while we're on the topic of hfs3, will hfs3 support a single stand-alone exe file like hfs2?
-
at the moment i'm very busy with hfs3 and hate to work on previous version, because it's very old stuff that's hard to deal with.
i cannot exclude doing some work with it in the future.
stand-alone exe, sure. it's already so.
it's not yet user-friendly, right, but it's still easier than apache.
right now i started working on the administration interface, the equivalent of the hfs2 main window. This alone will take me tens of hours of work.
-
at the moment i'm very busy with hfs3 and hate to work on previous version, because it's very old stuff that's hard to deal with.
i cannot exclude doing some work with it in the future.
stand-alone exe, sure. it's already so.
it's not yet user-friendly, right, but it's still easier than apache.
right now i started working on the administration interface, the equivalent of the hfs2 main window. This alone will take me tens of hours of work.
oh i see, well since i'm seemingly the only person affected by this range issue, it's not particularly important to anyone (including me), no need to prioritize it. good luck with the HFS3 project!
>stand-alone exe, sure. it's already so.
are you sure? when i try to run the 0.8.0 exe file standalone (extracting *just* the exe file from the archive), it just exits with this error
C:\Users\hans\Downloads>hfs
started 1/24/2022, 5:43:01 PM build 2022-01-23T13:59:18.879Z
cwd C:\Users\hans\Downloads
cannot read config.yaml Error: ENOENT: no such file or directory, open 'C:\Users\hans\Downloads\config.yaml'
C:\Users\hans\Downloads>echo %ERRORLEVEL%
0
seems there's a bug right there! it exits with errorcode 0, should surely be 1 or something, 0 is generally a success return code, no?
but also seems like this exe requires at the very least a config.yaml present ^^
-
you should read the README file
it says first time you have to rename config file
the rest must be improved ;)
-
i doubt anyone will actually add 416 to HFS2, but just in case, here is how i added 416 to PHP, the code might be interesting,
https://codereview.stackexchange.com/questions/280259/php-readfile-with-304-not-modified-and-http-206-partial-content-support-httpr