My view is a) the server was unavailable for this request due to all the other
requests it’s currently dealing with b) the connection was not idle, the client
is not at fault.
B.
> On 18 Apr 2019, at 22:03, Done Collectively wrote:
>
> Any reason 408 would be undesirable?
>
>
Any reason 408 would be undesirable?
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/408
On Thu, Apr 18, 2019 at 10:37 AM Robert Newson wrote:
> 503 imo.
>
> --
> Robert Samuel Newson
> rnew...@apache.org
>
> On Thu, 18 Apr 2019, at 18:24, Adam Kocoloski wrote:
> > Yes, we
I think the blacklist idea is a non-starter because of the storage overhead.
However I do agree that we should end the auto extension of session cookies.
You should get exactly whatever the configured duration is and no more. When
that cookie expires, or sooner if you’re smart, you can request
503 imo.
--
Robert Samuel Newson
rnew...@apache.org
On Thu, 18 Apr 2019, at 18:24, Adam Kocoloski wrote:
> Yes, we should. Currently it’s a 500, maybe there’s something more
> appropriate:
>
>
Yes, we should. Currently it’s a 500, maybe there’s something more appropriate:
https://github.com/apache/couchdb/blob/8ef42f7241f8788afc1b6e7255ce78ce5d5ea5c3/src/chttpd/src/chttpd.erl#L947-L949
Adam
> On Apr 18, 2019, at 12:50 PM, Joan Touzet wrote:
>
> What happens when it turns out the
What happens when it turns out the client *hasn't* timed out and we
just...hang up on them? Should we consider at least trying to send back
some sort of HTTP status code?
-Joan
On 2019-04-18 10:58, Garren Smith wrote:
> I'm +1 on this. With partition queries, we added a few more timeouts that
>
I'm +1 on this. With partition queries, we added a few more timeouts that
can be enabled which Cloudant enable. So having the ability to shed old
requests when these timeouts get hit would be great.
Cheers
Garren
On Tue, Apr 16, 2019 at 2:41 AM Adam Kocoloski wrote:
> Hi all,
>
> For once, I’m
