FAQ
Hi all,

I'm making a Golang Server-Sent Events client. It's basically a
long-running HTTP request. This also means that sometimes the client wants
to stop receiving before the server closes the connection (read: before the
Body is exhausted). The problem is that when I try to close the connection
in the intuitive way, it doesn't really close the connection. In my setup
(nginx, 60 second timeout), the server only sees the connection closing
after 60 seconds. This is not very good from a resource perspective. My
first attempts were like this:

/* close the streaming GET */
func (c *SseClient) Close() error {

     /* note that the following doesn't seem to really close the body if
      * there's still bytes to be read, so this is just a formal thing. */
     log.Println("sse/close: closing body")
     err := c.resp.Body.Close()
     if err != nil {
         return err
     }

     tr, ok := c.httpclient.Transport.(*http.Transport)
     if !ok {
         log.Println("sse/close: could not cast httpclient transport")
     } else {
         log.Println("sse/close: second cancel")
         tr.CancelRequest(c.req)
     }

     return nil

}


I had really though that tr.CancelRequest would do the trick, but it didn't.

It would seem that this issue was solved some time ago
by: https://code.google.com/p/go/issues/detail?id=3672
( https://codereview.appspot.com/7419050 ). However that does not seem to
be the case, I'm on Go 1.2 right now and even though the issue "seems" to
reference my problem, it persists (no pun intended).

Here's my current solution to the problem, which works well but feels dirty:

https://gist.github.com/aktau/9663194

So, my question is: is this the right way to solve the problem or is this a
recurring bug in Go? Will it be solved in the future or has it been solved
and did I just misunderstand?

--
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

  • Matt Harden at Mar 22, 2014 at 2:14 am
    You should Hijack() the connection in the SSE handler.

    On Thu, Mar 20, 2014 at 10:15 AM, wrote:

    Hi all,

    I'm making a Golang Server-Sent Events client. It's basically a
    long-running HTTP request. This also means that sometimes the client wants
    to stop receiving before the server closes the connection (read: before the
    Body is exhausted). The problem is that when I try to close the connection
    in the intuitive way, it doesn't really close the connection. In my setup
    (nginx, 60 second timeout), the server only sees the connection closing
    after 60 seconds. This is not very good from a resource perspective. My
    first attempts were like this:

    /* close the streaming GET */
    func (c *SseClient) Close() error {

    /* note that the following doesn't seem to really close the body if
    * there's still bytes to be read, so this is just a formal thing. */
    log.Println("sse/close: closing body")
    err := c.resp.Body.Close()
    if err != nil {
    return err
    }

    tr, ok := c.httpclient.Transport.(*http.Transport)
    if !ok {
    log.Println("sse/close: could not cast httpclient transport")
    } else {
    log.Println("sse/close: second cancel")
    tr.CancelRequest(c.req)
    }

    return nil

    }


    I had really though that tr.CancelRequest would do the trick, but it
    didn't.

    It would seem that this issue was solved some time ago by:
    https://code.google.com/p/go/issues/detail?id=3672 (
    https://codereview.appspot.com/7419050 ). However that does not seem to
    be the case, I'm on Go 1.2 right now and even though the issue "seems" to
    reference my problem, it persists (no pun intended).

    Here's my current solution to the problem, which works well but feels
    dirty:

    https://gist.github.com/aktau/9663194

    So, my question is: is this the right way to solve the problem or is this
    a recurring bug in Go? Will it be solved in the future or has it been
    solved and did I just misunderstand?

    --
    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.
    --
    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.
  • Nicolas Hillegeer at Mar 22, 2014 at 10:18 am
    Matt, if I'm not mistaken "hijacking" is something you do on the server
    side. My problem is with the client side (i.e.: making the connection
    _from_ the client to the server). One would normally use a http.Get for
    that, but I need to do some contortions for streaming gets...

    Am Samstag, 22. März 2014 03:13:43 UTC+1 schrieb Matt Harden:
    You should Hijack() the connection in the SSE handler.


    On Thu, Mar 20, 2014 at 10:15 AM, <nicolash...@gmail.com <javascript:>>wrote:
    Hi all,

    I'm making a Golang Server-Sent Events client. It's basically a
    long-running HTTP request. This also means that sometimes the client wants
    to stop receiving before the server closes the connection (read: before the
    Body is exhausted). The problem is that when I try to close the connection
    in the intuitive way, it doesn't really close the connection. In my setup
    (nginx, 60 second timeout), the server only sees the connection closing
    after 60 seconds. This is not very good from a resource perspective. My
    first attempts were like this:

    /* close the streaming GET */

    func (c *SseClient) Close() error {

    /* note that the following doesn't seem to really close the body if

    * there's still bytes to be read, so this is just a formal thing. */
    log.Println("sse/close: closing body")

    err := c.resp.Body.Close()
    if err != nil {

    return err
    }

    tr, ok := c.httpclient.Transport.(*http.Transport)

    if !ok {
    log.Println("sse/close: could not cast httpclient transport")

    } else {
    log.Println("sse/close: second cancel")

    tr.CancelRequest(c.req)
    }

    return nil

    }


    I had really though that tr.CancelRequest would do the trick, but it
    didn't.

    It would seem that this issue was solved some time ago by:
    https://code.google.com/p/go/issues/detail?id=3672 (
    https://codereview.appspot.com/7419050 ). However that does not seem to
    be the case, I'm on Go 1.2 right now and even though the issue "seems" to
    reference my problem, it persists (no pun intended).

    Here's my current solution to the problem, which works well but feels
    dirty:

    https://gist.github.com/aktau/9663194

    So, my question is: is this the right way to solve the problem or is this
    a recurring bug in Go? Will it be solved in the future or has it been
    solved and did I just misunderstand?

    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    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.
  • Matt Harden at Mar 22, 2014 at 4:36 pm
    You're right. I didn't read carefully enough before responding.

    On Sat, Mar 22, 2014 at 5:18 AM, Nicolas Hillegeer wrote:

    Matt, if I'm not mistaken "hijacking" is something you do on the server
    side. My problem is with the client side (i.e.: making the connection
    _from_ the client to the server). One would normally use a http.Get for
    that, but I need to do some contortions for streaming gets...

    Am Samstag, 22. März 2014 03:13:43 UTC+1 schrieb Matt Harden:
    You should Hijack() the connection in the SSE handler.

    On Thu, Mar 20, 2014 at 10:15 AM, wrote:

    Hi all,

    I'm making a Golang Server-Sent Events client. It's basically a
    long-running HTTP request. This also means that sometimes the client wants
    to stop receiving before the server closes the connection (read: before the
    Body is exhausted). The problem is that when I try to close the connection
    in the intuitive way, it doesn't really close the connection. In my setup
    (nginx, 60 second timeout), the server only sees the connection closing
    after 60 seconds. This is not very good from a resource perspective. My
    first attempts were like this:

    /* close the streaming GET */


    func (c *SseClient) Close() error {


    /* note that the following doesn't seem to really close the body if


    * there's still bytes to be read, so this is just a formal thing. */
    log.Println("sse/close: closing body")


    err := c.resp.Body.Close()
    if err != nil {


    return err
    }

    tr, ok := c.httpclient.Transport.(*http.Transport)


    if !ok {
    log.Println("sse/close: could not cast httpclient transport")


    } else {
    log.Println("sse/close: second cancel")


    tr.CancelRequest(c.req)
    }

    return nil


    }


    I had really though that tr.CancelRequest would do the trick, but it
    didn't.

    It would seem that this issue was solved some time ago by:
    https://code.google.com/p/go/issues/detail?id=3672 (
    https://codereview.appspot.com/7419050 ). However that does not seem to
    be the case, I'm on Go 1.2 right now and even though the issue "seems" to
    reference my problem, it persists (no pun intended).

    Here's my current solution to the problem, which works well but feels
    dirty:

    https://gist.github.com/aktau/9663194

    So, my question is: is this the right way to solve the problem or is
    this a recurring bug in Go? Will it be solved in the future or has it been
    solved and did I just misunderstand?

    --
    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...@googlegroups.com.

    For more options, visit https://groups.google.com/d/optout.
    --
    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.
    --
    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 20, '14 at 7:26p
activeMar 22, '14 at 4:36p
posts4
users2
websitegolang.org

2 users in discussion

Nicolas Hillegeer: 2 posts Matt Harden: 2 posts

People

Translate

site design / logo © 2021 Grokbase