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 <[email protected]>: >>> >>> I have an OpenBSD httpd(8) web server hosting security/clamav main.cvd >>> and >>> 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 >>> the >>> 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 >>> it >>> 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 >>> "nonblock_recv: >>> 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: >>> http://marc.info/?l=openbsd-cvs&m=148607400902939&w=2 >>> >>> Which didn't help. Then I also took out the range rewrite: >>> http://marc.info/?l=openbsd-cvs&m=148587359420912&w=2 >>> >>> 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 >>> httpd. >>> 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? >> >> Reyk >> > > 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 > later. > > 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. > > Tim.
