----------------------------------------
> Date: Tue, 24 Jun 2014 07:33:41 +0200
> From: [email protected]
> To: [email protected]
> CC: [email protected]; [email protected]
> Subject: Re: 3rd regression : enough is enough!
>
> Hi Patrick,
>
> On Mon, Jun 23, 2014 at 09:30:11PM -0400, Patrick Hemmer wrote:
>> This is unfortunate. I'm guessing a lot of the issue was in ensuring the
>> client timeout was observed. Would it at least be possible to change the
>> response, so that even if the server timeout is what kills the request,
>> that the client gets sent back a 408 instead of a 503?
>
> For now I have no idea. All the mess came from the awful changes that
> were needed to ignore the server-side timeout and pretend it came from
> the client despite the server triggering first. This required to mess
> up with these events in a very dangerous way :-(
>
> So right now I'd suggest to try with a shorter client timeout than the
> server timeout. I can try to see how to better *report* this specific
> event if needed, but I don't want to put the brown paper bag on
> timeouts anymore.
I fully agree.
But perhaps we can document the current behavior in those particular
conditions better, so that this is better known until we find a good
code-based solution.
What is the issue here exactly? When the client uploads large POST
requests and the server timeout is larger than the client timeout,
we will see a sD flag in the log? Is that all, or are there other
conditions in which a client timeout trigger a sD log?
Can it be workarounded completely by configuring the server timeout
larger then the client timeout?
Regards,
Lukas
