FAQ
Correct me if I'm wrong here, but I think there maybe an issue towards how
ctxhttp.Do would try to cleanup the residuals over the TCP connection when
the governing context is done. To begin, here is an excerpt of the comment
from the net/http/response.go:

// Body represents the response body.
//
// The http Client and Transport guarantee that Body is always
// non-nil, even on responses without a body or responses with
// a zero-length body. It is the caller's responsibility to
// close Body. The default HTTP client's Transport does not
// attempt to reuse HTTP/1.0 or HTTP/1.1 TCP connections
// ("keep-alive") unless the Body is read to completion and is
// closed.
//
// The Body is automatically dechunked if the server replied
// with a "chunked" Transfer-Encoding.

So, according to that, it seems like the goroutine at
x/net/context/ctxhttp/ctxhttp.go:60 will not properly cleanup the response
body. An additional statement of something like, io.Copy(ioutil.Discard,
resp.Body), should be added before it closes the body. Is this the right
idea? Or am I missing something, like resp.Body.Close() would actually read
everyone on that TCP connection?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Nigel Tao at Apr 1, 2016 at 12:20 am

    On Wed, Mar 30, 2016 at 9:32 AM, Guanhua Jiang wrote:
    So, according to that, it seems like the goroutine at
    x/net/context/ctxhttp/ctxhttp.go:60 will not properly cleanup the response
    body. An additional statement of something like, io.Copy(ioutil.Discard,
    resp.Body), should be added before it closes the body. Is this the right
    idea? Or am I missing something, like resp.Body.Close() would actually read
    everyone on that TCP connection?
    cbro (CC'ed) might know the answer.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Guanhua Jiang at Apr 1, 2016 at 12:53 am
    Thanks Nigel! I think if my experiment is done correctly, the difference
    without adding the io.Copy means that when context ends, the underlying TCP
    connection is forced to close. This may or may not be by design. If it is,
    I think I'd like to make a feature request some times, we don't necessarily
    want to close the underlying TCP connection.
    On Thursday, March 31, 2016 at 5:20:58 PM UTC-7, Nigel Tao wrote:

    On Wed, Mar 30, 2016 at 9:32 AM, Guanhua Jiang <steve...@gmail.com
    <javascript:>> wrote:
    So, according to that, it seems like the goroutine at
    x/net/context/ctxhttp/ctxhttp.go:60 will not properly cleanup the response
    body. An additional statement of something like, io.Copy(ioutil.Discard,
    resp.Body), should be added before it closes the body. Is this the right
    idea? Or am I missing something, like resp.Body.Close() would actually read
    everyone on that TCP connection?
    cbro (CC'ed) might know the answer.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Guanhua Jiang at Apr 7, 2016 at 6:05 am
    Bump. Should I maybe open a bug?
    On Thursday, March 31, 2016 at 5:52:59 PM UTC-7, Guanhua Jiang wrote:

    Thanks Nigel! I think if my experiment is done correctly, the difference
    without adding the io.Copy means that when context ends, the underlying TCP
    connection is forced to close. This may or may not be by design. If it is,
    I think I'd like to make a feature request some times, we don't necessarily
    want to close the underlying TCP connection.
    On Thursday, March 31, 2016 at 5:20:58 PM UTC-7, Nigel Tao wrote:

    On Wed, Mar 30, 2016 at 9:32 AM, Guanhua Jiang <steve...@gmail.com>
    wrote:
    So, according to that, it seems like the goroutine at
    x/net/context/ctxhttp/ctxhttp.go:60 will not properly cleanup the response
    body. An additional statement of something like,
    io.Copy(ioutil.Discard,
    resp.Body), should be added before it closes the body. Is this the right
    idea? Or am I missing something, like resp.Body.Close() would actually read
    everyone on that TCP connection?
    cbro (CC'ed) might know the answer.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Chris Broadfoot at Apr 7, 2016 at 6:19 am
    Sorry I missed this. I'm wary of reading from the response body, since it
    is unbounded.

    If you look at the cancelation code in transport.go, it doesn't read the
    body:
    https://golang.org/src/net/http/transport.go

    I think ctxhttp should mostly serve as a thin compatibility layer, and
    behave similar to req.Cancel in Go 1.6/1.7

    +Brad, the http expert.
    On Thu, Apr 7, 2016 at 4:05 PM, Guanhua Jiang wrote:

    Bump. Should I maybe open a bug?

    On Thursday, March 31, 2016 at 5:52:59 PM UTC-7, Guanhua Jiang wrote:

    Thanks Nigel! I think if my experiment is done correctly, the difference
    without adding the io.Copy means that when context ends, the underlying TCP
    connection is forced to close. This may or may not be by design. If it is,
    I think I'd like to make a feature request some times, we don't necessarily
    want to close the underlying TCP connection.
    On Thursday, March 31, 2016 at 5:20:58 PM UTC-7, Nigel Tao wrote:

    On Wed, Mar 30, 2016 at 9:32 AM, Guanhua Jiang <steve...@gmail.com>
    wrote:
    So, according to that, it seems like the goroutine at
    x/net/context/ctxhttp/ctxhttp.go:60 will not properly cleanup the response
    body. An additional statement of something like,
    io.Copy(ioutil.Discard,
    resp.Body), should be added before it closes the body. Is this the right
    idea? Or am I missing something, like resp.Body.Close() would actually read
    everyone on that TCP connection?
    cbro (CC'ed) might know the answer.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Guanhua Jiang at Apr 7, 2016 at 6:32 am
    Is the plan going forward to deprecate the ctxhttp and use the req.Cancel
    instead? Because we can essentially do req.Cancel = ctx.Done() to get
    similar behavior. I can only speculate since I saw that Brad pulled context
    into stdlib but not ctxhttp, :P.

    But, I think there could be a valid use case where one may want to maintain
    the underlying TCP connection rather than closing it. By not reading the
    body before closing, we are essentially closing the underlying TCP
    connection and asking the client to redo handshake. I think we should
    document this or maybe allow to read body as an option? The unboundedness
    can be potentially governed by the RoundTripper, e.g. the Transport.
    On Wednesday, April 6, 2016 at 11:19:23 PM UTC-7, Chris Broadfoot wrote:

    Sorry I missed this. I'm wary of reading from the response body, since it
    is unbounded.

    If you look at the cancelation code in transport.go, it doesn't read the
    body:
    https://golang.org/src/net/http/transport.go

    I think ctxhttp should mostly serve as a thin compatibility layer, and
    behave similar to req.Cancel in Go 1.6/1.7

    +Brad, the http expert.

    On Thu, Apr 7, 2016 at 4:05 PM, Guanhua Jiang <steve...@gmail.com
    <javascript:>> wrote:
    Bump. Should I maybe open a bug?

    On Thursday, March 31, 2016 at 5:52:59 PM UTC-7, Guanhua Jiang wrote:

    Thanks Nigel! I think if my experiment is done correctly, the difference
    without adding the io.Copy means that when context ends, the underlying TCP
    connection is forced to close. This may or may not be by design. If it is,
    I think I'd like to make a feature request some times, we don't necessarily
    want to close the underlying TCP connection.
    On Thursday, March 31, 2016 at 5:20:58 PM UTC-7, Nigel Tao wrote:

    On Wed, Mar 30, 2016 at 9:32 AM, Guanhua Jiang <steve...@gmail.com>
    wrote:
    So, according to that, it seems like the goroutine at
    x/net/context/ctxhttp/ctxhttp.go:60 will not properly cleanup the response
    body. An additional statement of something like,
    io.Copy(ioutil.Discard,
    resp.Body), should be added before it closes the body. Is this the right
    idea? Or am I missing something, like resp.Body.Close() would
    actually read
    everyone on that TCP connection?
    cbro (CC'ed) might know the answer.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Andrew Gerrand at Apr 7, 2016 at 6:35 am

    On 7 April 2016 at 16:32, Guanhua Jiang wrote:

    Is the plan going forward to deprecate the ctxhttp and use the req.Cancel
    instead? Because we can essentially do req.Cancel = ctx.Done() to get
    similar behavior. I can only speculate since I saw that Brad pulled context
    into stdlib but not ctxhttp, :P.
    No, the idea is to use request.WithContext passing a context that can be
    canceled. req.Cancel will be deprecated in 1.7.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Peter Waller at Apr 7, 2016 at 9:32 am

    On 7 April 2016 at 07:35, Andrew Gerrand wrote:
    No, the idea is to use request.WithContext passing a context that can be
    canceled. req.Cancel will be deprecated in 1.7.
    I was initially puzzled by this statement since req.Cancel was only just
    introduced. But then I found this discussion which frames things better for
    me:

    https://github.com/golang/go/issues/14660

    And I guess by "become deprecated" you mean, "no longer be the idiomatic
    way to do things"? Right now we have no choice but to use req.Cancel, and
    req.Cancel will remain compatible with future go code owing to the go 1
    promise.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Andrew Gerrand at Apr 7, 2016 at 1:45 pm
    Yes, your interpretation is correct.
    On 7 April 2016 at 19:31, Peter Waller wrote:


    On 7 April 2016 at 07:35, Andrew Gerrand wrote:

    No, the idea is to use request.WithContext passing a context that can be
    canceled. req.Cancel will be deprecated in 1.7.
    I was initially puzzled by this statement since req.Cancel was only just
    introduced. But then I found this discussion which frames things better for
    me:

    https://github.com/golang/go/issues/14660

    And I guess by "become deprecated" you mean, "no longer be the idiomatic
    way to do things"? Right now we have no choice but to use req.Cancel, and
    req.Cancel will remain compatible with future go code owing to the go 1
    promise.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMar 29, '16 at 10:32p
activeApr 7, '16 at 1:45p
posts9
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase