Re: Random “http first read error: EOF” errors

[Guillaume Quintard]

It does, I'm suspecting that the connection reuse is creating some issues,
probably because Apache is doing some non-standard stuff (protip: always
blame Apache).

-- 
Guillaume Quintard

On Thu, Mar 30, 2017 at 1:17 PM, Hazar Güney <hazarguney at gmail.com> wrote:

> "Connection: close" supersedes keep-alive behavior, is that correct?
>
> On Thu, Mar 30, 2017 at 2:08 PM, Guillaume Quintard <
> guillaume at varnish-software.com> wrote:
>
>> Can you try something: add 'set bereq.http.connection = "Close"; ' at the
>> beginning of vcl_backend_fetch and see if that helps?
>>
>> --
>> Guillaume Quintard
>>
>> On Thu, Mar 30, 2017 at 1:04 PM, Hazar Güney <hazarguney at gmail.com>
>> wrote:
>>
>>> MaxKeepAliveRequests 20
>>> KeepAliveTimeout 2
>>>
>>> Version is "4.1.3 revision 5e3b6d2". We have also seen "straight
>>> insufficient bytes" error with POST requests to a specific php script
>>> hosted by another backend and fixed it by using "pipe" instead of "pass"
>>> but this specific backend gives "http first read error: EOF" error. Another
>>> example from today:
>>>
>>> *   << BeReq    >> 126635444
>>> -   Begin          bereq 126635443 fetch
>>> -   Timestamp      Start: 1490870598.921499 0.000000 0.000000
>>> -   BereqMethod    GET
>>> -   BereqURL       XXXX
>>> -   BereqProtocol  HTTP/1.1
>>> -   BereqHeader    Host: XXXX
>>> -   BereqHeader    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
>>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
>>> -   BereqHeader    Accept: image/webp,image/*,*/*;q=0.8
>>> -   BereqHeader    Referer: XXXX
>>> -   BereqHeader    Accept-Language: tr-TR,tr;q=0.8,en-US;q=0.6,en;q=0.4
>>> -   BereqHeader    RIP: XXXX
>>> -   BereqHeader    X-Forwarded-For: XXXX
>>> -   BereqHeader    Accept-Encoding: gzip
>>> -   BereqHeader    X-Varnish: 126635444
>>> -   VCL_call       BACKEND_FETCH
>>> -   VCL_return     fetch
>>> -   BackendOpen    35 reload_2017-03-20T11:32:44.st2 10.35.78.11 80
>>> 172.17.0.2 48896
>>> -   BackendStart   10.35.78.11 80
>>> -   Timestamp      Bereq: 1490870598.922050 0.000552 0.000552
>>> *-   FetchError     http first read error: EOF*
>>> -   BackendClose   35 reload_2017-03-20T11:32:44.st2
>>> -   Timestamp      Beresp: 1490870598.922622 0.001124 0.000572
>>> -   Timestamp      Error: 1490870598.922627 0.001129 0.000005
>>> -   BerespProtocol HTTP/1.1
>>> -   BerespStatus   503
>>> -   BerespReason   Service Unavailable
>>> -   BerespReason   Backend fetch failed
>>> -   BerespHeader   Date: Thu, 30 Mar 2017 10:43:18 GMT
>>> -   BerespHeader   Server: Varnish
>>> -   VCL_call       BACKEND_ERROR
>>> -   BereqHeader    X-Varnish-Backend-5xx: 1
>>> -   VCL_return     retry
>>> -   Timestamp      Retry: 1490870598.922657 0.001159 0.000030
>>> -   Link           bereq 126832283 retry
>>> -   End
>>>
>>> On Wed, Mar 29, 2017 at 12:03 PM, Mattias Geniar <mattias at nucleus.be>
>>> wrote:
>>>
>>>> > Backend is Apache.
>>>>
>>>> In older Varnish versions, you could sometimes see a similar error;
>>>>
>>>> >   11 FetchError   c straight insufficient bytes
>>>>
>>>> The error message you’re seeing might be related, as it mentions the
>>>> EOF.
>>>>
>>>> This happens when the backend sends a Content-Length header that
>>>> doesn’t match the _actual_ content length it’s sending. In Apache, this was
>>>> commonly caused by a mod_deflate misconfiguration.
>>>>
>>>> For testing, could you try disabling Gzip either in your backend or
>>>> strip the Accept-Encoding header in Varnish to force a plain text response?
>>>>
>>>> Mattias
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20170330/4ffef180/attachment.html>