Should write errors be suppressed?

[cmcaine]

Julia 1.7.0
HTTP.jl 0.9.2
MbedTLS.jl 1.0.3

The first HTTP request from Firefox to an HTTP.jl server gives an IOError about the stream being closed or unusable. Maybe it shouldn't.

Thinking about this more generally, is it useful for HTTP.serve or RequestHandlerFunctions to print errors about this?

Perhaps we could suppress printing of write errors in the listen loop by default? Or possibly just errors from trying to write to a closed stream. It would be a fairly simple patch:

# in Servers.jl/listenloop

            @async try
                # verbose && @info "Accept ($count):  $conn"
                handle_connection(f, conn, server, reuse_limit, readtimeout)
                # verbose && @info "Closed ($count):  $conn"
            catch e
                if e isa Base.IOError && (e.code == -54 || e.code == -4077)
                    verbose && @warn "connection reset by peer (ECONNRESET)"

# These two lines are new
                elseif e isa Base.IOError && !isopen(io)
                    # Ignore errors from trying to write to a closed stream


                else
                    @error "" exception=(e, stacktrace(catch_backtrace()))
                end
            finally
                connection_count[] -= 1
                # handle_connection is in charge of closing the underlying io
            end

See also #546, JuliaWeb/Mux.jl#131

Reproducible example:

using HTTP

HTTP.serve() do req
    return HTTP.Response("Hello World!")
end

Navigate to localhost:8081 in firefox, the first time you visit there should be an error. If there isn't, try a new Julia session reload the page in firefox without cache (ctrl+f5).

[clarkevans]

@cmcaine Thank you for proposing a fix. @quinnj This class of non-actionable error propagation continue to irritate our user community. When browsers close the connection rudely, or even get connection reset by peer, there's frankly little that an application developer can do about it. The information is only interesting in the aggregate -- were there more of these today, relative to overall traffic? Even then, it's probably something of interest at the reverse-proxy. Any given disconnect / reset just isn't something that the back-end can recover from, having it show up in the error logs implies that it's something a developer could fix.

[quinnj]

I don't see any errors following the original issue, so going to close as stale.