forwarded

1 files changed, 29 insertions, 0 deletions

diff --git a/doc/bugs/could_webdav_be_more_resilient_to_timeouts__63__/comment_1_bb4130ae787e19757b849a6301129c34._comment b/doc/bugs/could_webdav_be_more_resilient_to_timeouts__63__/comment_1_bb4130ae787e19757b849a6301129c34._comment
new file mode 100644
index 000000000..8fd509a67
--- /dev/null
+++ b/doc/bugs/could_webdav_be_more_resilient_to_timeouts__63__/comment_1_bb4130ae787e19757b849a6301129c34._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-08-15T17:02:20Z"
+ content="""
+This last came up in 2014, at the time I disabled the http response timeout
+entirely with setResponseTimeout Nothing.
+
+Looking at Network.Protocol.HTTP.DAV.setResponseTimeout:
+
+	setResponseTimeout :: MonadIO m => Maybe Int -> DAVT m ()
+	#if MIN_VERSION_http_client(0,5,0)
+	setResponseTimeout rt = baseRequest %= \x -> x { responseTimeout = maybe responseTimeoutDefault responseTimeoutMicro rt }
+	#else
+	setResponseTimeout rt = baseRequest %= \x -> x { responseTimeout = rt }
+	#endif
+
+Looks like with recent http-client versions in the case of Nothing, rather
+than disabling the timeout, it now defaults to responseTimeoutDefault.
+Which is 30 seconds. Since I'm passing it Nothing to try to disable the
+timeout, that's kind of a problem! 
+
+I feel this is a bug in the DAV library. I could try to work around it
+with `Just maxBound`, that's many years worth of microseconds on 64 bit, but
+on 32 bit, it's somewhere under 10 minutes, which is really not good
+enough when the goal is to disable timeouts at this level entirely.
+
+Bug filed on DAV: <https://bugs.debian.org/872278>
+"""]]