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
>>> 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.


Reply via email to