[BUG] Broken HTTP response about pistache

[jdoverholt]

I think this is the same issue I'm seeing in issue #33.

[oktal]

Hello guys,

Thanks for reporting the issue. I'll try to take a look this week-end when I get some free time.

[oktal]

Alright so I will try to reproduce the issue in a unit test and hopefully fix it

[oktal]

Ok so I might have found the issue and pushed a fix for it: e1ad446

Following is my explanation of the bug.

When sending large files or large payloads over the socket, the internal kernel buffer reaches its limit (SO_SNDBUF) and ::send() then returns -1 with errno being EAGAIN, meaning that the buffer is full and the fd is not ready anymore to send data. When that happens, if Pistache does not own the underlying buffer it's trying to send, it will then try to make a copy of the buffer from the offset where it needs to start sending data when the fd becomes ready again. However, when attempting to copy a buffer from an offset > 0, I was triggering an exception because of an invalid if which is then catched by the handler and triggers the 500 Internal Server Error.

I just fixed the invalid if, let me know if it solves your issue, and I'll add some more unit-tests to make sure it works

[jeffvandyke]

I'm having a similar issue, on the latest master, sending a 338 KB file over the wire. As a test, I tried a file that has numbers 1-50000, with each number on its own line. What I'm seeing served from pistache is a file that has the same number of bytes plus 2, and at byte 143012 of 338896, the contents of the file wrap around and start over.

...
22015
22015
220171
2
3
4
...

the same thing happens further down at byte 280252 of 338896

...
21191
21192
211
2
3
...

I'm not really sure how to fix this problem, and I've got a deadline :( Is there any advice on what could be done?

[jeffvandyke]

Ok, on that last one, we fixed it so that we can serve large requests, and I will create a pull request.

[xoac]

Should be closed? #79 was merged.

[jeffvandyke]

Could be; my fix was aimed at serveFile(), and this does look very similar, though I'm not certain that this is the same problem. I did just test it, however, using response.send(), and it worked with a 1.4 MB response, so it's probably fixed. His code should probably be checked before and after the change though, to be certain.