The value passed as maxval, SIZE_MAX, doesn't fit on a long long int due
to signedness. It was causing legitimate range request to be discarded
as bad.
I tested it serving an mp4 and opening it with Firefox. A "range=0-" was
requested, and it triggered the bug.
---
http.c | 6 +++---
1 file chang
On Mon, 26 Oct 2020 11:49:33 +0100
José Miguel Sánchez García wrote:
Dear José,
> Funny, that's my current use case. All my CGI is through forms, so
> I'm currently running a separate server for the form handlers,
> regenerating the HTML and then redirecting to the recently updated
> page throug
On Sat, 31 Oct 2020 21:58:26 +
José Miguel Sánchez García wrote:
Dear José,
> The value passed as maxval, SIZE_MAX, doesn't fit on a long long int
> due to signedness. It was causing legitimate range request to be
> discarded as bad.
>
> I tested it serving an mp4 and opening it with Firefo
commit 4d3a6c5297015285f88a56cc47f6a53c372b1506
Author: Laslo Hunhold
AuthorDate: Sun Nov 1 00:10:54 2020 +0100
Commit: Laslo Hunhold
CommitDate: Sun Nov 1 00:10:54 2020 +0100
Prepare http_send_buf() http_recv_header() for blocking I/O
Signed-off-by: Laslo Hunhold
diff --g
commit dff98c0bcaef7be220c563ebaebd66f8c6704197
Author: Laslo Hunhold
AuthorDate: Sun Nov 1 00:27:46 2020 +0100
Commit: Laslo Hunhold
CommitDate: Sun Nov 1 00:27:46 2020 +0100
Use epoll/kqueue and worker threads to handle connections
This adds quite a bit of code, but is the
On 10/31/2020 11:27 PM, Laslo Hunhold wrote:
this is a great catch, thanks! But wouldn't it be better to use
MIN(SIZE_MAX, LLONG_MAX)?
I haven't found anything in the standard that puts "long long" and
"size_t" into any relation, which means, for me, that any case is
possible where either value
commit 7d26fc695d548b5a73305a97dce274a313e0f602
Author: Laslo Hunhold
AuthorDate: Sun Nov 1 01:47:11 2020 +0100
Commit: Laslo Hunhold
CommitDate: Sun Nov 1 01:49:27 2020 +0100
Prevent overflow in strtonum()-parameters
Make sure not to overflow the long long value. Given the
On Sun, 1 Nov 2020 01:15:32 +0100
José Miguel Sánchez García wrote:
Dear José,
> Good point! It could be the case that SIZE_MAX is smaller than
> LLONG_MAX. Honestly I don't know, but I would do what you are
> proposing just to be sure: it is the safest option, and maybe the
> compiler will tak