Overlogging "WARN: Error copying to client"

[elico]

I am running a very simple and tiny proxy:

...
func main() {
    proxy := goproxy.NewProxyHttpServer()
    proxy.Verbose = false
    proxy.OnRequest().DoFunc(
        func(r *http.Request, ctx *goproxy.ProxyCtx) (*http.Request, *http.Response) {
// Here Testing the domain and deciding what to do with the request.
            return r, nil
        })
    log.Fatal(http.ListenAndServe(":8080", proxy))
}

And I noticed too verbose output for expected cases such as:
..WARN: Error copying to client: read tcp 192.168.10.168:8080->192.168.10.131:53531: write tcp 192.168.10.168:8080->192.168.10.131:53531: use of closed network connection
And the cause is at:
https://github.com/elazarl/goproxy/blob/master/https.go#L264

The proxy in general is great but I want to turn it off in general and to enable it only for debugging.
I was wondering if a solution can be added without me forking and patch the source?
My current idea is to filter using a case by the error content and to allow the "proxy.Verbose = false" to disable\eliminate specific cases which are expected at runtime, such as clients closing connections.

[elazarl]

This is a good idea. I'll expose the log function.

Thanks for the kind words.

On Mon, May 2, 2016 at 9:44 AM, elico notifications@github.com wrote:

I am running a very simple and tiny proxy:

...
func main() {
proxy := goproxy.NewProxyHttpServer()
proxy.Verbose = false
proxy.OnRequest().DoFunc(
func(r _http.Request, ctx *goproxy.ProxyCtx) (_http.Request, *http.Response) {
// Here Testing the domain and deciding what to do with the request.
return r, nil
})
log.Fatal(http.ListenAndServe(":8080", proxy))
}

And I noticed too verbose output for expected cases such as:
..WARN: Error copying to client: read tcp 192.168.10.168:8080->
192.168.10.131:53531: write tcp 192.168.10.168:8080->192.168.10.131:53531:
use of closed network connection
And the cause is at:
https://github.com/elazarl/goproxy/blob/master/https.go#L264

The proxy in general is great but I want to turn it off in general and to
enable it only for debugging.
I was wondering if a solution can be added without me forking and patch
the source?
My current idea is to filter using a case by the error content and to
allow the "proxy.Verbose = false" to disable\eliminate specific cases which
are expected at runtime, such as clients closing connections.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#160

[drewwells]

It would be nice if these log messages specified if a request timed out from the client to the proxy or the server the proxy is attempting to communicate with. In general, the client dropping a connection is okay but the proxy dropping a connection to the server is pretty bad. I'm finding that slow server responses cause connections to be dropped. I didn't find any timeouts in the source, but it would be handy to know what connection was dropped, so we can debug that problem with timeouts.

I patched my source like this, but there's better ways func copyAndClose(ctx *ProxyCtx, w, r net.Conn, toProxy bool) {

[elazarl]

The timeouts are whatever timeouts set by stdlib net/http.

Generally speaking this sounds like a good idea.

On Thu, May 19, 2016 at 10:43 PM, Drew Wells notifications@github.com
wrote:

It would be nice if these log messages specified if a request timed out
from the client to the proxy or the server the proxy is attempting to
communicate with. In general, the client dropping a connection is okay but
the proxy dropping a connection to the server is pretty bad. I'm finding
that slow server responses cause connections to be dropped. I didn't find
any timeouts in the source, but it would be handy to know what connection
was dropped, so we can debug that problem with timeouts.

I patched my source like this, but there's better ways func
copyAndClose(ctx *ProxyCtx, w, r net.Conn, toProxy bool) {

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#160 (comment)

[AlmogBaku]

any update regarding this issue?
@drewwells what did you find out? who usually causing the timeout?

[elazarl]

I believe it should be solved with the patch that does TCP.readClose and
writeClose.

Is it still happening?

On Wed, Aug 10, 2016, 9:35 AM Almog Baku notifications@github.com wrote:

any update regarding this issue?
@drewwells https://github.com/drewwells what did you find out? who
usually causing the timeout?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#160 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAP4oiXsViFb8wW3goA4QWoh9Y_dSyvtks5qeXFBgaJpZM4IVJpQ
.

[drewwells]

Nope it's been working great with the fix

On Wed, Aug 10, 2016, 1:37 AM Elazar Leibovich notifications@github.com
wrote:

I believe it should be solved with the patch that does TCP.readClose and
writeClose.

Is it still happening?

On Wed, Aug 10, 2016, 9:35 AM Almog Baku notifications@github.com wrote:

any update regarding this issue?
@drewwells https://github.com/drewwells what did you find out? who
usually causing the timeout?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#160 (comment),
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAP4oiXsViFb8wW3goA4QWoh9Y_dSyvtks5qeXFBgaJpZM4IVJpQ

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#160 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOmE3RbuO_fkXdLAsocNdFcBJZGN7hUks5qeXGlgaJpZM4IVJpQ
.

[AlmogBaku]

when had this patch made?

I receive sometimes:

2016-08-10T06:12:45.485608687Z 2016/08/10 06:12:45 [159] INFO: error read response m.booking.com read tcp 10.2.70.5:47196->5.57.17.220:80: read: connection timed out:

[elazarl]

Can't it be a real problem?

A real client had timed out?

On Wed, Aug 10, 2016, 9:41 AM Almog Baku notifications@github.com wrote:

when is this patch made?

I receive sometimes:

2016-08-10T06:12:45.485608687Z 2016/08/10 06:12:45 [159] INFO: error read response m.booking.com read tcp 10.2.70.5:47196->5.57.17.220:80: read: connection timed out:

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#160 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAP4os3s0pU2jHuDIy3NyC0D3Iomcp0Gks5qeXJ7gaJpZM4IVJpQ
.

[AlmogBaku]

Yes, the browser just stuck and I can't access the page at all...

Also received weird message from the Client log, which indicated that the
Proxy closed the connection:

(AWAITING_INITIAL {tunneling}) [id: 0xf6f67156, L:/127.0.0.1:16549 -
R:/127.0.0.1:42125]: An IOException occurred on
ClientToProxyConnection: recvfrom failed: ECONNRESET (Connection reset
by peer)

On Wed, Aug 10, 2016 at 9:42 AM, Elazar Leibovich notifications@github.com
wrote:

Can't it be a real problem?

A real client had timed out?

On Wed, Aug 10, 2016, 9:41 AM Almog Baku notifications@github.com wrote:

when is this patch made?

I receive sometimes:

2016-08-10T06:12:45.485608687Z 2016/08/10 06:12:45 [159] INFO: error
read response m.booking.com read tcp 10.2.70.5:47196->5.57.17.220:80:
read: connection timed out:

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#160 (comment),
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AAP4os3s0pU2jHuDIy3NyC0D3Iomcp0Gks5qeXJ7gaJpZM4IVJpQ>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#160 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGCplhKfXGZ1AUQSigRFzcnpWY10yyGks5qeXK9gaJpZM4IVJpQ
.

http://www.rimoto.net/

www.rimoto.com http://www.rimoto.net/

Almog Baku

CTO & Cofounder *
Mobile: +972.50.2288.744
Social: * http://www.facebook.com/AlmogBaku
http://www.linkedin.com/in/almogbaku

[AlmogBaku]

My issue specified in #178 I'm not sure if they even related to each other.. but I guess they are

[elico]

@AlmogBaku By any chance the browser\client is chrome?

[ErikPelli]

The issue that caused all the logs has been resolved and is currently part of the master branch. Closing this issue.