Bringing this back up from the depths. I kept rolling back to older httpd
code and forgetting about this :(
I still see this issue in 6.3 A new packet cap look the same.
On Tue, April 18, 2017 4:23 pm, trondd wrote:
> On Tue, April 18, 2017 3:46 pm, Reyk Floeter wrote:
>>> Am 18.04.2017 um 20:53 schrieb trondd <tro...@kagu-tsuchi.com>:
>>> I have an OpenBSD httpd(8) web server hosting security/clamav main.cvd
>>> daily.cvd files. Upon upgrading to 6.1, freshclam can no longer
>>> successfully fetch the cvd files.
>>> Freshclam does a request for the first 512 bytes of the files to check
>>> dates in their header. Then pulls the rest of the file if needed. It
>>> looks like it pulls the *whole* file again. It doesn't pick up where
>>> left off.
>>> With httpd from 6.0, fully patched, this was working fine. Whith 6.1,
>>> freshclam would request the 512 chunk, then timeout with
>>> recv timing out (30 secs)".
>>> Knowing there were a couple of changes to ranges in httpd, I started
>>> rolling things back. I took out the pipelining fix:
>>> Which didn't help. Then I also took out the range rewrite:
>>> And bingo. Freshclam happily pulled it's now much out of date daily
>>> database. :)
>>> I don't know if freshclam is doing something wacky here or if it's
>>> It does return the requested byte range, and I was able to pull a range
>>> with curl as well. I don't know another test case for this off hand.
>> Do you have any more details like request/response HTTP headers with old
>> and new code?
> Yes. Hopefully these attach properly. Only have access to web mail from
> here so scream at me if all you get is garbage and I can resend properly
> ASCII output from the tcpdump showing success and failure cases. I have
> the full binary pcaps if needed. Comparing quickly, I see 6.1 sends the
> Partial Content response header in a seperate packet from the content.
> Previous code didn't do that.