Best way to listenAndServe both http/https?

[elij]

What is the best way to serve (currently the same resources) over both http and https in a single instance?

Currently I am doing something like this:

http://play.golang.org/p/WAothdzLNW

Does this seem reasonable? Is there a better way?

Thanks.

[elij]

Note. I missed a wg.Done() in the second goroutine.

http://play.golang.org/p/Q0_JsVDh0R

Also, blindly wrapping in log.Fatal instead of explicitly handling err would probably mean that the waitGroup isn't involved much anyway (other than preventing premature exit).

[Patrick Mylund Nielsen]

If you know that you're going to serve both, then you can simply

go func() {

        if err := ListenAndServeTLS(...); err != nil {

                log.Fatal(...)

        }

}

if err := ListenAndServe(...); err != nil {

                log.Fatal(...)

}

If you don't--as it seems from your example, then maybe it's simpler to

go func() { ListenAndServeTLS(...) }

go func() { ListenAndServe(...) }

ch := make(chan bool)

<-ch

As you say, the WaitGroup doesn't do much in this example since log.Fatal calls os.Exit(1).

[elij]

Thanks Patrick.

I like your solution (just using a blocking chan read) -- less ceremony (simpler) and will achieve the same thing for my use case.

On Wednesday, July 4, 2012 at 2:57 PM, Patrick Mylund Nielsen wrote:

> If you know that you're going to serve both, then you can simply
>
> go func() {
> if err := ListenAndServeTLS(...); err != nil {
> log.Fatal(...)
> }
> }
> if err := ListenAndServe(...); err != nil {
> log.Fatal(...)
> }
>
> If you don't--as it seems from your example, then maybe it's simpler to
>
> go func() { ListenAndServeTLS(...) }
> go func() { ListenAndServe(...) }
> ch := make(chan bool)
> <-ch
>
> As you say, the WaitGroup doesn't do much in this example since log.Fatal calls os.Exit(1).

[Patrick Mylund Nielsen]

Yeah, that makes more sense.

On Thu, Jul 5, 2012 at 1:00 AM, Peter Thrun <peter...@ymail.com> wrote:

I like your solution (just using a blocking chan read) -- less ceremony (simpler) and will achieve the same thing for my use case.  

I think it's better to use 

 

  select {}

when you want to block forever.  The select statement is one line and that one line communicates the intent.

[elij]

Ah. Thanks for that.

On Wednesday, July 4, 2012 at 4:00 PM, Peter Thrun wrote:

> > I like your solution (just using a blocking chan read) -- less ceremony (simpler) and will achieve the same thing for my use case.
>
>