Noob questions

[Tamás Gulácsi]

See gowut, for example.

[Carlos Castillo]

Although I am about to say a lot, it is still only an high-level response to your questions.

1.a)

Go compiles to native binaries for a single OS/Architecture, the myapp.exe will only run on systems similar to the one you built it on.

Eg: Windows x86 (32-bit) binaries will only work on those machines, and on 64-bit x86-64 Windows machines

The portability of go is that the entire standard library (essentially everything documented on golang.org) has no platform dependencies, so most "pure-go" programs and libraries can be built to run anywhere go does without modification. The only non-portable package in the standard library is the "syscall" package, which contains the low-level system dependent types & interfaces used by the standard library to implement it's portable interface.

You still will need to build a different executable for each OS/ARCH you wish to support. Cross compiling in Go however isn't too difficult, but AFAIK it requires you to use the command line interface and source code install, as well as there are some features which can't be cross-compiled (anything using cgo). Most pure-go projects should be able to cross-compile, but it's still a good idea to build on the target environment directly, both "to be sure", as well as to be able to run tests (to be really sure).

1.b) I'm not familiar with Android enough to be able to answer about the support of Go there. The OS (android) is not an officially supported Go platform, but the hardware architecture (arm) is. On the iOS side, both the OS (darwin - ie: OSX) and the architecture are supported (arm, again), but not together, in some part due to the restrictions imposed by Apple. In the most recent version of Go (1.1) the main technical limitation was dealt with but official support is probably some time away.

I believe that the runtime environment for the Chrome OS is essentially the Chrome browser, which means no native binaries, so no Go, but I could be wrong (it is running linux underneath).

2.a)

Building a Go that serves HTTP requests fall into 3 main camps:

• Building a Go program that acts as the HTTP server, and handles all requests. This is what most of the code in the standard library is built for.
• Building a program that does the above, but has a proxy in front of it for load balancing or other services where fast or existing code is already present.
• Building a Go program that is a helper program to another server via a protocol like CGI, Fastcgi, etc... Go includes support for both CGI and FastCGI, but it requires a slightly different program design as the Go program has a different set of responsibilities and life-cycle.

If you are wanting to make a Go program to run "inside" Apache, you will probably be using the third option. The way I have done this on OSX, where apache is built-in, is to use the Apache config option ExecCGI; a tutorial to set up Apache's CGI support (not go specific) is at http://httpd.apache.org/docs/2.0/howto/cgi.html . CGI is a protocol where webserver starts up another program (in this case the go exe), and passes it the parsed request information in environment variables, and using stdin (eg: for POST data). The program then responds by writing a response to stdout. You can do this manually yourself, but the net/http/cgi provides a simple interface, nearly identical to the stand alone one, to handle the request. It uses the same net/http.Handler interface as the built-in server package so you can (mostly) use the same handlers for a stand-alone server (option 1 & 2) as for CGI. I have in-fact made a private package that can be used to build servers that can run either as a CGI program or in stand-alone mode, but it does require knowledge about how these two modes differ.

2.b) Most examples you will see are for building a go program that acts as a self-contained web-server, since it is fairly simple to do so in Go, and has had quite a lot of work done to improve it's performance w.r.t. existing web-servers. That means that there is one EXE, with nothing between it and the internet, handling all requests for data on a given network socket. This makes it very easy to build and test your apps, as nothing needs to be installed or running on the target machine for you to enter (in this case) "http://localhost:9999" into a web-browser to see the output of the program.

3.a) yes, using cmd/exec is probably the most straight-forward way to ask the OS to open a URL for you. The exact method / command differs with the OS though, but most OS's provide a utility command to open web-sites. Eg on windows, the command is "start <URL>", on Mac OS X its "open <URL>", and on Linux you can often use "xdg-open" (but I'm not 100% sure). Alternatively, if you know the path to the browser you want to use you could call it directly, but that is generally not a good idea, as it might not be the user's desired browser, and it might not exist.

3.b) The most portable way (works with non HTML5 browsers) would be to have a heartbeat request made by the page, IE: if the pages refresh every 10 seconds, then no requests for 30 seconds probably means the browser window/tab was closed. This could be done by refreshing the entire page (<meta http-equiv="refresh"...>), or by making AJAX requests. A more accurate way would be to use websockets (see: http://caniuse.com/websockets for support in modern browsers), as there is then a way for the server to know when the client closes the connection.

4) This is definitely one way to do it, and Go gives you all the pieces necessary to build the entire end-to-end process (if necessary) as it has fairly easy to use http server and client code. Also if you want to implement encryption, and / or message digests to ensure authenticated, error checked updates, those features exist in the standard library as well. Because of go's static compilation, in many cases all you'd need to transmit is a single file, and no installer needs to be run, nor does the environment need to be set up (eg: install DLL's). If you need to send app+data, you can either use multiple requests, or the built-in zip support to pack/unpack a single zip file. Again all these features have implementations in pure Go, as part of the standard library, so you have far fewer portability concerns.

On Thursday, May 30, 2013 12:37:51 PM UTC-7, Jim Ellis wrote:

I have been out of programming for the past decade.  I recently stumbled across Go and this is the first language I have seen in this past decade that has caught my interest as I think it shows the ability to create a program that can .  I like how it produces a compiled program that I believe is suppose to be able to run on different platforms, it is "c like", designed to take advantage of multi core processors, and I believe also distributed web apps.

The first "problem" I encountered is that Go does not have a user interface.  I can grasp how to create a go program to perform a task, but what caused me some conceptual problems is the gap of how to know when to perform the task and what to do with the result.

So I kept reading and looking into this issue, and I believe the answer for me is HTML5/CSS3.  Html allows for the typical user input items (text box, check box, list, button).  And after looking at the new features in html5, such as the canvas and flexbox, as well as go's ability to work with an html template, and that provides the way to show the result.  So this gives me a constructive direction to work with.

Now we get to some practical issues, which is where the questions arise as I still have some things that I have not figured out yet.

#1.  Executable file.

I have myapp.go which performs a simple task.  It is compiled into myapp.exe.

I am using Win7 on my pc with eclipse for the IDE.  Can I take the myapp.exe and run it on a mac and/or linux pc?  What about an apache web server?

This is the first test to get my eventual end program to be usable on different platforms.  I want to run it on an apache server to prepare the web site pages.  I also want a "desktop" program that will do most of the processing so the server is not over used.  (see #2 for reason of this.)

1B)  From what I understand, at this time myapp.exe will not run on Android.  So for a droid app, I would just wrap the html5 so the app could be downloaded from the google play app-store.

Is it planned to have a go program be able to run on droid?

What about the chrome os?

------

#2.  Getting the "myapp" to run on the apache web server.

I am using a hosted web site on a shared server.  

  A) What do I need to do to get the myapp.exe to run on the web server?

      Can I load it to the root directory of the web site, or even put it in a sub directory?

  B) The examples I have looked at use http.ListenAndServe("localhost:9999", nil) this won't work for the actual web site.  What should this be set to?

-----

#3.  Running on the desktop.

Because of the shared server that has limits on the use, I want to offload some of the processing to the desktop.  I can do this for both preparing the pages, and also for some computations.  The myapp would run on the desktop, pull data from the website, and then display the result in the browser that is set to work with "localhost".

As mentioned, I have used the localhost to get the myapp to work with a browser.  But I would like to integrate this a bit more.  I would like to have a shortcut that runs the myapp.exe file, and have it open the browser with the browser directed to "localhost".  

Am I correct that this can be done using the os/exec package?  (using cmd.start)

3B)  What is the best way to end the myapp program when the browser is closed?

-----

#4.  Desktop version updating.

I realized that if the os/exec package can be used to start another program, then I can create a "launcher" program.

The "launcher.exe" would be downloaded from the server and placed in a directory on the pc.

The "launcher.exe" program would be the one that has a shortcut set to it.  When ran it would check the website for the latest version of the myapp program, if needed download it from the website, and put it in the correct directory on the pc.

Then the launcher.exe would start myapp.exe.

Am I on the right track with this line of thought?

----

The answers to these questions should tie up the loose ends where I will have a better grasp on the concepts and can get to work on the details.

Thanks,

Jim.

[Jim Ellis]

I checked this thread last night and saw the reply from András Belicza about gowut.  I did not have time to look at it in-depth, but bookmarked the pages.

I had time to look at them more today, and I would like to thank Andras as that answers quite a few of the UI questions that I had.

@Carlos Castillo,

Your "high level" answers were exactly what I am looking for.  I am the type where I want to get a good grasp on the concept, 

and then I will worry about the details on how to make the concept work.

"You still will need to build a different executable for each OS/ARCH you wish to support."

I appreciate the frankness of that answer, and your explanation that went with it.  

On your answer for 2a.  I understand the first 2 camps your described.  The 3rd one I am not familiar with, so this sounds like it will be more of a learning curve for me to be able to use an apache web server for my website.

I had thought that apache ran on Linux, so after reading your first answer I thought that I would need to just build the exe for linux and it would be good.  But from what I am seeing in your second answer, it sounds like it is a bit more involved than that, so thank you for the link to the apache cgi tutorial.  

For 2B I think my question may have been confusing.  So let me restate it.

I know that to run "myapp.exe" on my pc I use localhost for the port to be listened to.

What do I use in place of that when I run the program on a web server?

Thanks for the answers on 3.  You are right, I would want to use the users default browser.  

Thanks for adding the information that each platform has a slightly different call that is needed to open the browser.  That information really helps!

Thanks for the websockets hint, that sounds like it will be the best approach.

And thanks for confirming my ideas on #4 would work.

-----------------------------------

Based on the answers I can now lay out a rough plan of action.

First thing I will do is check with my web host to see if they will let me use a windows server to test with.  If it works out well, then I will move my site to the windows server.

This would be the fastest way for me to get "up and running".  

If not, then I will take the extra time and work through that apache tutorial.

** I will need to figure out what to use in the listen command when I start the program on the server.

The first version will have a download to windows for the "desktop" version of the program.

Once I get the site and program going the way I want, then I can work on taking care of the "p"'s and "q"s to get the desktop program to work on macs and linux pc's.  This would involve taking care of platform specific commands and the compiling of the program for each platform.

Thanks for the assistance,

Jim.

[Jim Ellis]

correction to previous post.  Thanks to Tamas Gulacsi for pointing to gowut.

I think I found the answer to 2B.

I was looking at more examples and found this:

http.ListenAndServe(":8080", nil); err != nil {

Is that the proper way to set it up for when it runs on a website?

The "localhost" is only put in that line when you want to force it to use your pc.

[Carlos Castillo]

What I meant about the different camps is that you can

1. Have the Go app as the web-server (stand alone mode),
2. Have a stand alone server in go on a non-standard port, and have requests to an existing Apache server (or nginx, lighthttpd, etc...) redirect the user to that server
   
3. Have the main server (apache and friends), somehow pass the request through to a Go app, and return the response back to the user (the user only interacts with apache)

With #1, the user sees / accesses one executable (your go app), which must do all the work (handling all requests), and so you have to put the effort in to do things like serve static files (fairly simple in go), compress output to minimize traffic (a little harder), or anything else a traditional webserver might do in addition to handle HTTP requests.

With #2, you can serve a static website with Apache, and have links on pages to dynamic content be served by the go server. This means that the majority of the hits and traffic is handled by apache, but your go app is contacted when dynamic things need to be done. This often has a very small config cost, but things such as firewalls, the Same origin Policy, etc... can get in your way if you aren't too careful.

With #3, the apache server is the only online entity that users contact, but apache silently (to them) hands the work to the go app, and returns the response back. This has the benefit that as long as the user can access the main site they'll have no problems with the dynamically generated parts because to them it will just be another request to the same web-site. Also benefits that the web-server brings to static content (like compression), can transparently be applied to your app. The downside of this approach is on your end: the server needs to be configured to enable a protocol like CGI (with appropriate restrictions on how it's used), and your app often has to be restructured because it will be receiving requests and sending out responses differently and in the case of CGI, the program has a different life-cycle, the program is started once per request, and is expected to exit at the end of the request.

Even with these hassles the most popular option is usually #3 if you are integrating into an existing site since it's invisible to the user, and most of the work is done by tried and true code. PHP for example works in this model, and it is either run as a CGI program, a FastCGI server, or most commonly a dynamically loaded module in the web-server (mod_php). Go doesn't support the third option as it doesn't produce dynamically linked code.

Jim.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/8VjyHRYMl2Q/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Carlos Castillo

[Carlos Castillo]

I didn't catch the ":8080" vs "localhost:8080" before so I wasn't sure what you were asking. Yes, if you provide an address (and not just a port) in a listener declaration, then the requests can only be received if sent to that address. Since localhost only exists on the current machine, no other machine can send requests to a server listening there.

Also, calling http.ListenAndServe(...) sets up your go app *as* a web server, so if you are trying to integrate it into an existing server (eg: apache), you are now running two servers on the same machine, one at port 80, the default port, and the other at whatever port you specify. There can be some subtle problems (as mentioned before same origin policy & firewalls) that you can trip over if you work this way.

--

You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/8VjyHRYMl2Q/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Carlos Castillo

[Jim Ellis]

Carlos,

I really appreciate your patience and explanations.  I am not a "network" person, so this is quite a bit of new stuff for me to get a grasp on.  When I have worked on web sites I either just used html for a static page or php for a dynamic page.  I did not have to get into the server set up.  

So I have been trying to get the concept in place of how a go program would fit into this.  I spent the weekend giving your replies some thought.

I am still having problems though figuring out how to proceed where I can use go.  So I would like to talk through where I am at and what problems I am seeing.

First, your further explanation about the 3 camps is very helpful.  

It would appear that #3, the cgi approach is one that are saying is the most popular.  A few questions I have would be how would concurrency be handled with this approach?

Doesn't this involve more server resources as it is constantly restarting and re-initializing the program on every request?  

How would a chat program be handled in this approach where there is a constant stream of data going to the server and being displayed to many different clients?

Let me give you an outline of what I want to do with go.

I belong to a social club and I want to redo the club web site.

We have the main page that tells people about the club.

We have a "join us" page.

We have a members section. 

The main part of the members section is a forum.

In the members section we want to have a chat room.

And I would like to add a program where people can put in some base information and it will perform calculations to give them an answer to help them know what parts they need to complete a project.

(The chat and project calc stuff are things I was thinking of putting into a desktop program to try to lesson the processing of the server.)

The club is using a shared web server from a web hosting company.

Here are things I have a good grasp on the concept, and for me are just a matter of putting the details in place..

I have researched how to use session and static cookies to figure out if the person is logged in.

I can do the coding to determine the persons access level.  Whether they are a guest, a member, a moderator, or an administrator.

I am working out the best approach for a menu, and the page template layout.  (I want to make sure it shows up well on a mobile devise as well as a desktop browser.)  

I can do the coding to store info in a database and retrieve it.

I can do the page layout where people can enter data and review it.

From what I had read, I wanted to use the url for just the site navigation, such as club.com/members/chat to tell go to load the chat page.  Or club.com/members/forum to load the forum page.  (and likely have a further sub level to define the specific forum to view.

I wanted to use "POST" for the data to be posted.  I wanted to keep this data out of the url so I could make it easier to make sure that the program is safe from sql injection attacks.  Also, I think it makes the overall look a lot cleaner.

But now I question whether I can use the post method this way with the cgi route?

With cgi how does the page know to call the go program?

With cgi could I have multiple go programs in the cgi-bin directory, and how would the page know which one to call to execute?

I also question how well will the templates show up sending them via the cgi output format?

If I were to use the #1 approach of using go as the web server, would that mean that I could not do a static html page, or a php page?

With the #1 approach, would it work on a shared server, where there are multiple web sites on the server, and only the web site of my club is running go as a server?

Would #2 wind up being the best approach where concurrency could be used as well as the chat room stuff, and where the server would not be starting and initializing the program so much?

What approach would you take to do this and why?

Thanks,

Jim.

PS.  A comment that I hope the go team would see and think about.

From what I have seen go is showing a lot of potential as a new language.  It can do quite a bit of processing and handle things "behind the scenes".  For those that are "systems" type of programmers, that know what it takes to create a language, and know the very deep things that take place on a system level, such as how to make a web server, go is "usable".

I believe that go is reaching the point though where the big issue is how programmers that are not "systems" people will be able to use go.  A good example is the difficulties I am having figuring out how actually be able to use go on a web site.  I am running into a lot of difficulties in how to get it set up to run.

I believe there are only a few types of web servers.  So why isn't there a guide on how to get a go program to run on the different server types?

There are quite a few examples of how to use go with a web browser, which gives us 1 UI type.  But there is not much out there on how to get go to work with other UI's, such as QT.

It would be very helpful if there was a guide on how to do this.

IMHO for go to be successful the programmers that are not "systems" type of people need to be shown how to get go to work with a user interface, and how to get a program to run on a desktop, a web server and when it is working, on a mobile device.

[Kiki Sugiaman]

On 6/3/2013 10:05 AM, Jim Ellis wrote:
> Carlos,
>
> I really appreciate your patience and explanations. I am not a
> "network" person, so this is quite a bit of new stuff for me to get a
> grasp on. When I have worked on web sites I either just used html for
> a static page or php for a dynamic page. I did not have to get into
> the server set up.
> So I have been trying to get the concept in place of how a go program
> would fit into this. I spent the weekend giving your replies some
> thought.
>
> I am still having problems though figuring out how to proceed where I
> can use go. So I would like to talk through where I am at and what
> problems I am seeing.
>
> First, your further explanation about the 3 camps is very helpful.
>
> It would appear that #3, the cgi approach is one that are saying is
> the most popular. A few questions I have would be how would
> concurrency be handled with this approach?
> Doesn't this involve more server resources as it is constantly
> restarting and re-initializing the program on every request?

That is what CGI is and not only it is resource intensive, it's slow and
it gets hairy pretty fast in terms of code logic. Nobody in 2013 would
recommend you writing CGI unless when you have a very simple application.

> How would a chat program be handled in this approach where there is a
> constant stream of data going to the server and being displayed to
> many different clients?
>
> Let me give you an outline of what I want to do with go.
>
> I belong to a social club and I want to redo the club web site.
> We have the main page that tells people about the club.
> We have a "join us" page.
> We have a members section.
> The main part of the members section is a forum.
> In the members section we want to have a chat room.
> And I would like to add a program where people can put in some base
> information and it will perform calculations to give them an answer to
> help them know what parts they need to complete a project.
> (The chat and project calc stuff are things I was thinking of putting
> into a desktop program to try to lesson the processing of the server.)
>
> The club is using a shared web server from a web hosting company.

Is the shared hosting a hard requirement? Unlike php which comes
preconfigured with many shared hosting, you probably have to write
cgi/fastcgi if you want to use Go on shared hosting. We know what the
problem with cgi is.
Fastcgi while is fast and resource efficient, is very hard to write from
scratch.
Today, you can spin up a VM for as little as $5/month and scale up only
when you grow and run with existing libraries other people have written,
so you don't have to write your own session, cookies, and DB handling or
html templating.

You can also implement chat on the browser, but it's really up to you.

>
> Here are things I have a good grasp on the concept, and for me are
> just a matter of putting the details in place..
> I have researched how to use session and static cookies to figure out
> if the person is logged in.
> I can do the coding to determine the persons access level. Whether
> they are a guest, a member, a moderator, or an administrator.
> I am working out the best approach for a menu, and the page template
> layout. (I want to make sure it shows up well on a mobile devise as
> well as a desktop browser.)
> I can do the coding to store info in a database and retrieve it.
> I can do the page layout where people can enter data and review it.
>
> From what I had read, I wanted to use the url for just the site
> navigation, such as club.com/members/chat to tell go to load the chat
> page. Or club.com/members/forum to load the forum page. (and likely
> have a further sub level to define the specific forum to view.
> I wanted to use "POST" for the data to be posted. I wanted to keep
> this data out of the url so I could make it easier to make sure that
> the program is safe from sql injection attacks. Also, I think it
> makes the overall look a lot cleaner.
>
> But now I question whether I can use the post method this way with the
> cgi route?
>
> With cgi how does the page know to call the go program?

Basically this is web server configuration work.
For Apache: http://httpd.apache.org/docs/2.4/howto/cgi.html

I think Go is just made to fulfill a different kind of expectation.
Shared hosting comes preconfigured with a certain stack (web server +
script runtime such as php, asp.net, etc + probably mysql). So when you
host on those environments, you install your script and configuration
files and static assets. A Go application is basically its own
independent executable, so when you deploy a Go app, you are deploying
an executable. It also comes with a web server ("net/http") as part of
the standard library, which most Go people are using.

So while you can put a Go app behind any web-server if you prefer, it's
really not necessary. A runtime is also not necessary. What you need to
run a Go app is an OS.

Also, don't let the term "systems programmer" get in your way. While you
can use Go to access deep parts of the OS kernel, you really don't have
to. Go runs directly on top of the OS and that is all you need to know
as an application developer. (Well, it probably means that you have to
perform root-level OS administration on your server but that's not
systems programming :P)

Best

> There are quite a few examples of how to use go with a web browser,
> which gives us 1 UI type. But there is not much out there on how to
> get go to work with other UI's, such as QT.
> It would be very helpful if there was a guide on how to do this.
>
> IMHO for go to be successful the programmers that are not "systems"
> type of people need to be shown how to get go to work with a user
> interface, and how to get a program to run on a desktop, a web server
> and when it is working, on a mobile device.
>

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

[Carlos Castillo]

I realize now that you were asking about using Go to to build a desktop app (with a web-based UI), and I went off on a tangent about integrating go programs in existing web-servers. To be fair, you did ask about that as well. I have some answers and follow up about servers below. I write a separate post about client-side apps.

Sorry if it looked like I was pushing you to use CGI (or implying it was the most popular), I wasn't certain the exact situation you were in w.r.t. your web-server, and I brought up CGI because it's the simplest to configure, and has decent support in the go standard library.

 Looked at another way, the 3 approaches are:

1. Have Go run everything
2. Have 2 servers (1 Apache + 1 Go) running simultaneously (and not necessarily on the same machine)
3. Have the Apache as the main server, and using delegate programs (Go / PHP) to service certain requests.

These aren't exactly mutually exclusive groups, for example where I used to work, we had an Apache server for static content, and a Tomcat server for Java servlet based dynamic content. By using mod_jk to connect the two servers, we were essentially combining 2&3: two servers, where one is the invisible delegate of the other. We did this not because Tomcat couldn't handle static content (it could, we in fact tested our site locally that way), but the overhead of having the Java servlet system process a simple file request was not considered worth it in production. On the other hand, writing separate CGI programs would incur (as you and Kiki noted) a start up cost on every request, which in Java can get pretty bad.

You are right about some of the shortcomings of CGI, because it involves starting up your go program with every request, so there is extra latency; and semi-persistent data (eg: sessions) are harder to do and often necessary. I have never tried to set up FastCGI before (either in general or for go) but it should help with some of the problems of CGI.

Although there are limitations with every technique and approach, they are all supposed to support HTTP, which means that POST requests and cookies shouldn't be a problem no matter how you choose to solve the problem. The thing most likely to trip you up will be the sessions. Most session systems involve two parts: a session id, which is usually added to the HTTP headers (often as a cookie or part of the URL), and a server-side storage indexed by that id. The issue is the later, as you will probably not be able to access with go the session data of programs in other environments (you mentioned you had PHP services). This isn't necessarily a blocking issue, you just need to either have a way of passing data from the foreign app to the go app (preferably not through the user), or have the user re-login to the go app.

If you decide to go with a go stand alone server, you won't have a problem with static content, as you can either use http://golang.org/pkg/net/http/#FileServer to create a handler that serves a url on the site from a folder on the server, or inside an existing http.Handler you can use http://golang.org/pkg/net/http/#ServeFile to serve an individual file from disk.

The design of Go with respect to building web-applications is that it provides simple to use, mostly low-level features instead of a high-level abstraction, such as with PHP. The parts for dealing with HTTP (the protocol), running a server, routing requests, handling cookies, compression, HTML templates, etc... are all separate and can be used, ignored, or replaced as needed. If you want a more complicated request router, or full sessions you can add pieces from the gorilla toolkit to your program (http://www.gorillatoolkit.org/) without replacing the other parts of your program.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/8VjyHRYMl2Q/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Carlos Castillo

[Carlos Castillo]

Comparing a Go client Desktop app with Web interface to a HTML/JS/CSS app served by the server they share the following benefits:

• Simple to create and modify interface, as it's HTML/CSS/JS although YMMV
• Portable Interface (rendered by browser)
• Easy to write code to communicate with the server

A pure web-app has the following advantages:

• Can better integrate with the website
• Only one layer of processing and communication between interface and the server
• No installation and automatic upgrades implicit in the design
• Portability is greater / simpler (ie: only need browser)

The Go app has the following advantages:

• Better access to native machine resources (CPU, Disk)
• A local cache of UI resources (no need to hit main server for large UI)
• Client side processing is generally more efficient (than JS)

If you use a UI package to build your go program (such as https://github.com/skelterjohn/go.wde):

• Better integration with native UI (most likely)
• No Browser dependency & runs separately from browser (eg: no hack to close app)
• One level of network communications (client<->server) instead of 2
• Possible size benefit (net/http is a large dependency)

If your writing a chat program, there seems to be little benefit to writing a go program with web-ui, compared to a HTML/JS/CSS client served by the web-server. There is no real processing that needs to be done, and most of the work of the app is centered around the message sent to from the server (no real client side processing). The only real benefit the go program would have is that it would not have to be restricted to browser technologies to comunicate with the server/other clients. Before websockets became part of HTML5 and integrated into most browsers, the communication between client & server could only be done with regular HTTP requests (or AJAX) which is complicated to get right for both clients and servers, as opposed to using traditional sockets, something a browser won't allow JavaScript to use.

I'm not sure of the requirements of your other client-side service, but if it actually does prove beneficial to use go for it, then integrating the chat into the program could then make sense.

If you need to make a go server, possibly to support web-sockets on the server, then go clients make more sense, because you would have a shared codebase, and easier methods to pass data back and forth. For example the Gob encoding in go allows you send structs back and forth over the websocket with little configuration needed.

[Jim Ellis]

@ksug,

Thanks for the answers.  CGI is out of consideration.

"So while you can put a Go app behind any web-server if you prefer, it's 

really not necessary. A runtime is also not necessary. What you need to 
run a Go app is an OS."

It is too bad I did not have a camera running, as the expression on my face would have been priceless to watch as that little man made it to the top floor and turned on the lights.  :)

It finally dawned on me that what I was trying figure out is how to run that executable on the hosted server. 

I have been in contact with the tech support of the hosting company and am just waiting for them to provide me the details on logging in via ssh to be able to start the myapp.exe program, and let me know the best folder to put it in.

As to "systems programmer", it doesn't get in my way.  I am in awe at those that can create a programming language and know how to manipulate a computer at the "systems" level.  That is just a level I have never had to use.  My experience has been with creating routines for gathering data, processing it, storing it in a db and retrieving it for viewing/edit and reports.

Thanks!

[Jim Ellis]

Carlos,

You are right, part of my my questions were about using go for a desktop app.  Those parts were easily answered, such as using a "launching app" and loading a browser when the app starts.  Also, with the "localhost" I have a good grasp on using go for the desktop app.

Your "tangent" about go and web servers is the area that I was really struggling with and was having a hard time grasping what I needed to do.  So your comments on it have been very helpful!

The tech support that hosts the web server did a little test for me.  He ran a simple "hello world" app, and used port 8080 for the program to listen to.  So both apache and go were running on the same server.

I believe that this is the approach I am going to take.

This way I can keep the current site up and running while I create the new site.  

Once the go program (myapp.exe) is up and running, I can either use htaccess or an index.html page to redirect the browser to port 8080 so the go program can take over and run the site.

I believe this will offer the best of all worlds as it will have apache to handle the low level parts you mentioned, and go will handle the actual processing to do what I want to do with the site.

And as I mentioned in the last reply, I finally grasped the issue I was struggling with as figuring out how to run the go program (myapp.exe) on the server.

Thanks for the reference to the gorilla toolkit. 

I think for now I am going to use html5/css3 for the UI.  I think it provides an interface where I don't have to worry about platform issues with it, the browser can do that for me.  HTML has the buttons, input boxes, etc to let the user interact with the program, and it has the mechanisms to display the output.  

I think that the canvas element in it might be the best solution for one program I have in mind that will have a graphical output.

Once again, thank you for all of the help, I greatly appreciate it!

Jim.

[Jim Ellis]

New Questions:  (I plan to write a "how to for dummies" based on these questions/answers, to try to make it easier on others as they set up a web server.)

1.  Placement of myapp.exe on web server.  (discussion of pros/cons & can it be done?)

This is a question on what directory would be best to ftp the program to.

a)  When I go into my ftp client, the "root" directory of the website is  /var/www/html 

This is where the "index.html" file is at that a web browser would read.

b)  Can a "lower level" directory on the sever be used?

I could create a /var/goprg directory and load the program there.

Which directory would be best.  Would there be "path" issues for either one.  Which would be better for security, such as if I want to create a text file to store some settings or data.  Is there any issues with the "listen" command based on what folder the program resides in?

I am thinking that the lower level directory would work, and because it is a lower level it is "hidden" from simple web browser access, so this would make it "safer" from the casual hacker.  It would take someone getting access to the server to get to the program or any files that I create that are stored in the lower level directory or path such as /var/goprg/datafiles

#2.  SSH shell.

When it comes to unix, for me it is pretty much so "u-what?"  :)

To start the go program (myapp.exe) I need to log into the server via ssh and issue a command to start the program.

Also, if the program "hangs" or becomes non-responsive I would need to log in and kill the program and then re-start it.

AND, when I go to update the program I would need to kill it, ftp the new version and then start the new program.

This means you need a log in for the server that has ssh privileges.  (bin/bash is what I have it set to and I am using Putty for the ssh client)

Once you log in you need to go to the directory where the go program is loaded at.  

For my website control panel, when I add a user to the website, and log in ssh with that user I have to change directories in this manner:

cd /var/www/html

or

cd /var/goprg

That will place me in the directory with the go program (myapp.exe)

you can do a "ls" command to list the files and it should show up.

The question I have now is what command do I use to start the go program, where it will remain running after I close the ssh client?

To stop the program, I would log in, and then type in the command "ps" to show all processes.

To terminate/stop the program you take the PID (job/process number) 

Kill #####    (the PID )

 

If that does not work then do:

Kill -9 #####  (PID)

When done type "exit" to end the ssh client session.

These are the steps that I was having so many problems with.  I think making a little tutorial out of this would be helpful to those that like me are not familiar with the "lower level" stuff.

Thanks,

Jim.

[Kiki Sugiaman]

On 6/5/2013 12:00 PM, Jim Ellis wrote:
> New Questions: (I plan to write a "how to for dummies" based on these
> questions/answers, to try to make it easier on others as they set up a
> web server.)
>
> 1. Placement of myapp.exe on web server. (discussion of pros/cons &
> can it be done?)
> This is a question on what directory would be best to ftp the program to.

Before answering your questions, I want to point out the difference
between a typical Apache setup and a typical Go app setup:
Apache is a static file server by default and application server by
configuration (remember you can configure it to serve the output of a
cgi app when you need some dynamic logic).
Your Go app should be an application server by default and a file server
by configuration, that is, until you specify by code that all the files
in the folder ~/myAwesomeGoApp/public/css/ .....(example) is publicly
accessible, no folder in your server will be publicly accessible.
As such, your directory structure should reflect logic and convenience
instead of access criteria.

Research how to run a process as a daemon in *nix, or as a service in
windows.
More elaborate setup will utilize some form of "process monitor".
Example:
http://mmonit.com/monit/documentation/monit.pdf
http://supervisord.org/

I feel that this topic is more appropriate for sysadmin discussion
forums. Feel free to come back here to discuss your Go code :)

Best

>
> To stop the program, I would log in, and then type in the command "ps"
> to show all processes.
>
> To terminate/stop the program you take the PID (job/process number)
> Kill ##### (the PID )
> If that does not work then do:
> Kill -9 ##### (PID)
>
> When done type "exit" to end the ssh client session.
>
> These are the steps that I was having so many problems with. I think
> making a little tutorial out of this would be helpful to those that
> like me are not familiar with the "lower level" stuff.
>
> Thanks,
>
> Jim.
>

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

[Jim Ellis]

ksug,

Thanks for the links to monit and supervisord.

I have a lot of information to sift through.  I even found a g+ post by Andrew Gerrand from a year ago that was showing how to use go via cgi on a particular website host.
So for someone like me that is not familiar with the network admin type of stuff, this is fairly complicated and confusing.

"I feel that this topic is more appropriate for sysadmin discussion 

forums. Feel free to come back here to discuss your Go code :)  "

If you know of a system admin discussion forum that is geared towards setting up a server to use go, PLEASE point it out to me!

If you don't, then I feel my questions are appropriate for this forum.  I have 1 very simple argument to make to support this.  

If I can not get my web site to use a go program, then I do not have any reason to write any go code!

Go is geared towards "processing", it "does stuff" with data.  But it needs to have inputs, where a user enters data and makes a request for processing to be done.  And when that processing is done, there needs to be a way to display the results to the user.

In go there is the net/http library.  And I am seeing that html5 is showing a lot of promise to be a user interface.

What I am finding quite ironic, is that in the comments I have seen, the go creators have said go is designed more for web processes and not really for a "desktop program".  But yet, the way that the net/http is set up, it is very easy to use it for a desktop program by using localhost in the browser url!

But to set it up on a website is a major problem!!!!!

And this is where I think that go is failing to get widespread support.

For those that are low level developers, that know "systems" type of issues, which quite often include the network admin type of issues, it is not a big deal and they can make go work.

But for those of us that are not at that level, these problems with getting go to work on a web site is a major stumbling block.  And if it is too complicated it winds up where a person will just pass up on go and use a different language that they can get to work on the web site.

Consider this.  With php all I need to do is use an ide, whether it is notepad or one that has features built into it.  I create a text file with the php tags, the code to "do stuff", give it a php extension, ftp it to the web site, and it runs!

Basically all I have to do is learn the correct php syntax.  This makes it a pretty low barrier to overcome!

For go, you have to learn the syntax, which is not that big of a deal.  The development of go has made this something that is not a major obstacle.

There is a bit of an issue on the compiling to run on the different platforms.  Such as to do a localhost test I would compile to windows.  When it is ready for my website, then I need to compile it to run on linux.  

Then there is the barrier that has been my major problem, what to do to get it where when I type in the website address in a browser, the go program will work.

My goal here is to get a guide developed to help people overcome this barrier.  IMHO, right now this barrier is something that I believe is hindering the widespread acceptance of go.

Jim.

[Matt Silverlock]

On Thursday, June 6, 2013 8:54:01 PM UTC+8, Jim Ellis wrote:

And this is where I think that go is failing to get widespread support.

For those that are low level developers, that know "systems" type of issues, which quite often include the network admin type of issues, it is not a big deal and they can make go work.

But for those of us that are not at that level, these problems with getting go to work on a web site is a major stumbling block.  And if it is too complicated it winds up where a person will just pass up on go and use a different language that they can get to work on the web site.

Consider this.  With php all I need to do is use an ide, whether it is notepad or one that has features built into it.  I create a text file with the php tags, the code to "do stuff", give it a php extension, ftp it to the web site, and it runs!

Basically all I have to do is learn the correct php syntax.  This makes it a pretty low barrier to overcome!

For go, you have to learn the syntax, which is not that big of a deal.  The development of go has made this something that is not a major obstacle.

There is a bit of an issue on the compiling to run on the different platforms.  Such as to do a localhost test I would compile to windows.  When it is ready for my website, then I need to compile it to run on linux.  

Then there is the barrier that has been my major problem, what to do to get it where when I type in the website address in a browser, the go program will work.

The "ease" at which you can just upload a bunch of PHP files is two-fold: PHP is designed to be embedded alongside HTML—ignoring, for a moment, the more sensible MVC approach—and PHP hosting (typically Apache + mod_php or FCGI) is extremely widespread due to its age and popularity.

I also don't believe Go is "failing to get widespread support": it's still a (very) young language. It, likely many other modern languages, take a different tack from PHP and enforce a bit more structure: this ultimately makes the barrier to entry a little higher. PHP isn't without it's own problems though: it's just that typically don't show themselves when you're just starting out. Note that the "issues" (to use your phrasing) you're having re: compiling won't ever change: Go is a compiled language, and targets different architectures. Cross-compiling in Go, thankfully, is super easy and makes writing on platform X and deploying to platform Y pretty easy. 

Creating a basic web application in Go is really no harder than doing so with a minimal Python or Ruby framework—and Go, like those languages, has a ton of libraries (gorilla, et. al) that can keep you from having to reinvent the wheel. 

I mean no offense by this, but judging by the way you refer to some technologies ("browser URL", "desktop program", "html5"), I think some of your issues are just due to a lack of experience with modern development environments. Yes, there's a bit more to learn these days, but in exchange you gain a lot more flexibility.

To answer your root question: just use the built-in HTTP server and router to serve your content for testing ("localhost"). Dump your static files behind the /static route. When you need to deploy into production, set up Apache or nginx w/ FCGI or as a reverse HTTP proxy. There are literally hundreds of guides on how to set up both of those web servers in FCGI or reverse HTTP "modes", and it's generally pretty simple if you just want vanilla HTTP. My advice is to cross that bridge when you get to it: start building an application first.

[Kiki Sugiaman]

On 6/6/2013 7:54 AM, Jim Ellis wrote:
> ksug,
>
> Thanks for the links to monit and supervisord.
> I have a lot of information to sift through. I even found a g+ post
> by Andrew Gerrand from a year ago that was showing how to use go via
> cgi on a particular website host.
> So for someone like me that is not familiar with the network admin
> type of stuff, this is fairly complicated and confusing.
>
> "I feel that this topic is more appropriate for sysadmin discussion
> forums. Feel free to come back here to discuss your Go code :) "
>
> If you know of a system admin discussion forum that is geared towards
> setting up a server to use go, PLEASE point it out to me!
>
> If you don't, then I feel my questions are appropriate for this forum.
> I have 1 very simple argument to make to support this.
> If I can not get my web site to use a go program, then I do not have
> any reason to write any go code!

You are facing the same deployment hurdles as what you would face if you
were to deploy a Python-Django or Ruby on Rails application for example.
So I meant it in that sense.
I didn't point you to a specific site because I felt that your problem
was a bit open ended, that is (and I'm making assumptions here) you need
to brush up a bit on OS administration, background vs foreground
processes, etc.
http://www.webhostingtalk.com/ is a good place for hosting and
deployment discussions.
It wasn't my intention to drive you away from this list, it's just that
you'll get better answer for your questions somewhere else.

>
> Go is geared towards "processing", it "does stuff" with data. But it
> needs to have inputs, where a user enters data and makes a request for
> processing to be done. And when that processing is done, there needs
> to be a way to display the results to the user.
>
> In go there is the net/http library. And I am seeing that html5 is
> showing a lot of promise to be a user interface.
> What I am finding quite ironic, is that in the comments I have seen,
> the go creators have said go is designed more for web processes and
> not really for a "desktop program". But yet, the way that the
> net/http is set up, it is very easy to use it for a desktop program by
> using localhost in the browser url!
> But to set it up on a website is a major problem!!!!!

What's serving on localhost:8080 for example, is actually a web app. You
can deploy it on mysite.com:80 and it will be accessible to the world as
http://www.mysite.com. The same way you can run Apache on your desktop,
but after you deploy it on a proper web-host, your Apache becomes a
fully fledged website.
The difference is that Apache comes preconfigured by a lot of web hosts
due to it adoption.

>
> And this is where I think that go is failing to get widespread support.
> For those that are low level developers, that know "systems" type of
> issues, which quite often include the network admin type of issues, it
> is not a big deal and they can make go work.
> But for those of us that are not at that level, these problems with
> getting go to work on a web site is a major stumbling block. And if
> it is too complicated it winds up where a person will just pass up on
> go and use a different language that they can get to work on the web site.
>
> Consider this. With php all I need to do is use an ide, whether it is
> notepad or one that has features built into it. I create a text file
> with the php tags, the code to "do stuff", give it a php extension,
> ftp it to the web site, and it runs!
> Basically all I have to do is learn the correct php syntax. This
> makes it a pretty low barrier to overcome!

Yes, Go has a higher barrier to entry than PHP, for more power and
flexibility. But it's not any higher than something like Ruby on Rails
for example.
Good luck with your guide!

>
> For go, you have to learn the syntax, which is not that big of a deal.
> The development of go has made this something that is not a major
> obstacle.
> There is a bit of an issue on the compiling to run on the different
> platforms. Such as to do a localhost test I would compile to windows.
> When it is ready for my website, then I need to compile it to run on
> linux.
>
> Then there is the barrier that has been my major problem, what to do
> to get it where when I type in the website address in a browser, the
> go program will work.
>
> My goal here is to get a guide developed to help people overcome this
> barrier. IMHO, right now this barrier is something that I believe is
> hindering the widespread acceptance of go.
>
> Jim.
>
>

[Jim Ellis]

Matt,

The comparison to php was a bit of a crude one.  I would not be here trying to learn this if I did not think that go could do a lot more than php.

Actually, this is the first time in a very long time that I have been excited about a language, as I can see a lot of potential for using go where in the end it will save me a lot of work and be usable across many different platforms in one form or another.

BTW, yes, the compile to each platform is something that will have to be done, which is a cost of it being a compiled program, a cost that IMHO is well worth it.  I listed it because it is just another step that has some details that have to be paid attention to so it is done right.

And yes, you are right, I am behind the times in regards to modern dev environments.  I have been away from programming for a while, a big part of it has been due to my impression that there was not a language that would do what I wanted to do.  The "juice was not worth the squeeze".

Once again, this shows that I see a lot of potential for go.

>"start building an application first"

I have.  :)  

I am taking it in measured steps.  I found how easy it is to use the start of the program on my desktop with localhost.  So the next step was to put it on the website and see it run there.  Thus, this thread......

For the next few days I am going to break this down to 2 steps.  First I need to get the program compiled to run on the linux server.

Then I need to digest all of the information I have gathered and start "playing" with the program on the linux box.

It looks like I will have to do a lot of trial and error to figure out what will work.  (From everything I have seen, it appears to me that the program will be ran in the background on the linux box.)

>"What's serving on localhost:8080 for example, is actually a web app."

I understand that part of it.  My pc is acting like a server to have the program interact with the browser.

>"You can deploy it on mysite.com:80 and it will be accessible to the world as 
http://www.mysite.com."

Will this cause a conflict between the go program and apache?

(this was one of the things I figured would be part of the "trial and error".)

>"Yes, Go has a higher barrier to entry than PHP, for more power and 
flexibility. But it's not any higher than something like Ruby on Rails 
for example. "

I think it is higher than ruby on rails.  With one little search I found several links to "how to's" that contain instructions on what a person needs to do to get ruby on their apache server.

(from that very quick glance, it appears that the instructions I found install the runtime on apache, and then when you write the app it is handled in a manner similar to php)

>"Good luck with your guide! "

Thanks.  As you can see in this thread, a lot has been said, but there have not been any clear instructions so I am left with a lot of trial and error.

I am hoping that once I am done with this, it will make for a good wiki entry on the steps needed to be followed.

[Kiki Sugiaman]

On 6/6/2013 2:40 PM, Jim Ellis wrote:

Matt,

The comparison to php was a bit of a crude one.  I would not be here trying to learn this if I did not think that go could do a lot more than php.

Actually, this is the first time in a very long time that I have been excited about a language, as I can see a lot of potential for using go where in the end it will save me a lot of work and be usable across many different platforms in one form or another.

BTW, yes, the compile to each platform is something that will have to be done, which is a cost of it being a compiled program, a cost that IMHO is well worth it.  I listed it because it is just another step that has some details that have to be paid attention to so it is done right.

And yes, you are right, I am behind the times in regards to modern dev environments.  I have been away from programming for a while, a big part of it has been due to my impression that there was not a language that would do what I wanted to do.  The "juice was not worth the squeeze".

Once again, this shows that I see a lot of potential for go.

>"start building an application first"

I have.  :)  

I am taking it in measured steps.  I found how easy it is to use the start of the program on my desktop with localhost.  So the next step was to put it on the website and see it run there.  Thus, this thread......

For the next few days I am going to break this down to 2 steps.  First I need to get the program compiled to run on the linux server.

Then I need to digest all of the information I have gathered and start "playing" with the program on the linux box.

It looks like I will have to do a lot of trial and error to figure out what will work.  (From everything I have seen, it appears to me that the program will be ran in the background on the linux box.)

>"What's serving on localhost:8080 for example, is actually a web app."

I understand that part of it.  My pc is acting like a server to have the program interact with the browser.

>"You can deploy it on mysite.com:80 and it will be accessible to the world as 
http://www.mysite.com."

Will this cause a conflict between the go program and apache?

(this was one of the things I figured would be part of the "trial and error".)

If you deploy the go exec as a standalone app, there will be no Apache in the picture.

If you use Apache or any other web-server as a proxy, then the picture more or less becomes like this:

------http request------> :80 | Apache | ----req----> :8080 | Go app |
<-----http response-----                           <----resp----

(I know indentation will murder the cute picture above, oh well)


If you use fcgi with Apache, it will be similar but now your go app has to speak the protocol:

------http request------> :80 | Apache | ----fcgi_protocol----> :8080 | Go app |
<-----http response-----                           <----fcgi_protocol----

>"Yes, Go has a higher barrier to entry than PHP, for more power and 
flexibility. But it's not any higher than something like Ruby on Rails 
for example. "

I think it is higher than ruby on rails.  With one little search I found several links to "how to's" that contain instructions on what a person needs to do to get ruby on their apache server.

(from that very quick glance, it appears that the instructions I found install the runtime on apache, and then when you write the app it is handled in a manner similar to php)

Only because RoR has been around longer. The principle/mechanics is similar. A Ruby runtime/interpreter is needed because Ruby is a scripting/interpreted language.

>"Good luck with your guide! "

Thanks.  As you can see in this thread, a lot has been said, but there have not been any clear instructions so I am left with a lot of trial and error.

I am hoping that once I am done with this, it will make for a good wiki entry on the steps needed to be followed.

[Kiki Sugiaman]

Also, take a look at various PaaS/cloud options like Google App Engine. I personally dislike PaaS' because I have to learn the specifics of their API and I like root control of my OS. But I'm *guessing* that they will minimize your job of daemonizing and monitoring your running app.

On 6/6/2013 2:40 PM, Jim Ellis wrote:

[Matt Silverlock]

On Friday, June 7, 2013 4:30:46 AM UTC+8, ksug wrote:

Also, take a look at various PaaS/cloud options like Google App Engine. I personally dislike PaaS' because I have to learn the specifics of their API and I like root control of my OS. But I'm *guessing* that they will minimize your job of daemonizing and monitoring your running app.

Heroku can also be a good option. Go binaries can easily be run there, there is very little API tie-in (usually just if you go down the add-on route) and you don't need to worry about the sysadmin side. dotCloud also supports Go, although they don't have Go 1.1 support yet (there's a 1.0.3 config that needs a fork...).

The problem with going down the "Linux" route from day zero is that you have a fair bit more to configure than just your web server--which can get in the way of actually making something.

[Jim Ellis]

A little update.

I installed LiteIDE as it has the selection to compile to linux.  I also had to install all the stuff to get that to work.  I am now able to compile a program that will run on my linux/apache web server.

BUT,,,,,,,,,,  I am having a "problem" with the listenandserve command.

        http.HandleFunc("/", handler)

http.HandleFunc("/stop/", stopHandler)

err := http.ListenAndServe("localhost:8080", nil)

We all know that the "localhost" makes the program run on my pc, what I would refer to as a "desktop" program.  One "problem" I am now having when I compile the program to run on my windows pc is that it opens a dos/command window.  There is no prompt showing, and while that window is open I can direct a browser to localhost:8080 and see the hello page.

I then changed the listenandserver to (":8080", nil)

I compiled this and it runs on my pc, the browser will show the page at localhost:8080.

I compiled it to linux32, FTP'd the file to the web server, ssh'd in and started it.

I went to mysite.com:8080 and the page shows up.  So it is running on the web site and is viewable!  yeah!  :)

BUT, here is the problem.  It is a shared server.  So a person with a different url on that server can also see the program.  othersite.com:8080 showed the same hello page.   This is a problem, I can not have my program show up on other web sites!

I then made the next change to the listenandserve command to ("http://mysite.com:8080", nil)

It compiled to linux32, I ftp'd it to the server, and when I ssh'd in to run it, I got the error message of "too many colons http://mysite.com:8080"

It would not run!

Would someone please be kind enough to give me some instructions on what I need to do to get the program where it only shows up on my web site, not on every site that is on that server!

And for the last step, what is the command or steps that I will need to take to redirect the apache server to feed the base url requests to the 8080 port.  

Thanks,

Jim.

ps.  I am getting very close to where I can post that guide.  I just have these few small details to get taken care of.

[James Bardin]

On Monday, June 10, 2013 3:43:54 PM UTC-4, Jim Ellis wrote:

I went to mysite.com:8080 and the page shows up.  So it is running on the web site and is viewable!  yeah!  :)

BUT, here is the problem.  It is a shared server.  So a person with a different url on that server can also see the program.  othersite.com:8080 showed the same hello page.   This is a problem, I can not have my program show up on other web sites!

I then made the next change to the listenandserve command to ("http://mysite.com:8080", nil)

It compiled to linux32, I ftp'd it to the server, and when I ssh'd in to run it, I got the error message of "too many colons http://mysite.com:8080"

It would not run!

The ListenAndServe  function declares what ip address and port to bind the server to. If your shared hosting gives you your own ip address, then you wan to put it there (the empty ip address is a wildcard, and will listen on all interfaces).

You very likely won't have your own IP on a shard server, which requires that you specify a "virtual host". Luckily, ServeMux can match against the host name as well (http://golang.org/pkg/net/http/#ServeMux). Adding your hostname to the handler pattern should take care of only responding on your intended domain. You probably don't want to do this however if you intend to put the go service behind a reverse proxy. It will just complicate things, and you can handle the virtual host definitions in the frontend server.

[Jim Ellis]

James,

Thanks for the answer.  I have some followup questions to it.

If listenandserve is looking for an IP address, why are there examples that show using http://url.com  ?

(note:  that is just a question out of frustration of trying to follow an example that sends you down a wrong path)

I will take a look at the servemux.  Would you happen to know of an example where it is used, so that I would make sure I use it correctly?

What is a reverse proxy?  Your last part of the answer is confusing, as you say here is what you need to do (servemux), but don't do it as "it will complicate things and you can handle the virtual host definitions in the frontend server".  How would this be handled in the frontend server, and would this be better than doing the servemux?

Thanks,

Jim.

[Kiki Sugiaman]

Reverse proxy refers to a setup where you put your app behind something
like Apache or Nginx, with your app being just an http server (as
opposed to something like fcgi or module app).
When you use this setup, you should configure your front-end server to
do the domain binding and not your Go app.

[James Bardin]

On Monday, June 10, 2013 4:38:48 PM UTC-4, Jim Ellis wrote:

James,

Thanks for the answer.  I have some followup questions to it.

If listenandserve is looking for an IP address, why are there examples that show using http://url.com  ?

(note:  that is just a question out of frustration of trying to follow an example that sends you down a wrong path)

Where are these examples? ListenAndServe takes an address string, and 'http://' isn't part of an address, it's the URI scheme (well, http is the scheme name, then the separator, and start of the authority part). You can use a hostname as long as the system can resolve it to an ip address to which it can bind.

 

I will take a look at the servemux.  Would you happen to know of an example where it is used, so that I would make sure I use it correctly?

You are using the DefaultServeMux already: http://golang.org/pkg/net/http/#HandleFunc

 

What is a reverse proxy?  Your last part of the answer is confusing, as you say here is what you need to do (servemux), but don't do it as "it will complicate things and you can handle the virtual host definitions in the frontend server".  How would this be handled in the frontend server, and would this be better than doing the servemux?

Well, I only skimmed some of the previous discussion, but others had suggested you put the go service behind a web server, so as to easily combine your static assets with your application. This isn't really a discussion for golang-nuts though; you need to do some more reading up on these systems, and how they work if you intend to deploy an application in this manner. You're missing a lot of background here, and it makes it difficult to communicate precisely (I wouldn't have known to differentiate between a hostname and a URI for example, which I can see is confusing if you don't know the difference).

[Jim Ellis]

Here is the code of the program I am trying to get run on my website.

package main

import (

    "log"

    "net/http"

    "os"

)

const resp = `<html>

    <head>

        <title>Simple Web App</title>

    </head>

    <body>

        <h1>Simple Web App</h1>

        <p>Hello Jim!</p>

    </body>

</html>`

func handler(w http.ResponseWriter, r *http.Request) {

    w.Write([]byte(resp))

}

func stopHandler(w http.ResponseWriter, r *http.Request) {

    go gopanic()

}

func gopanic() { // very ugly way to abort the listenandserve

    panic("stop request called")

}

func main() {

    http.HandleFunc("/", handler)

    http.HandleFunc("/stop", stopHandler)

    err := http.ListenAndServe(":8080", nil)

    if err != nil {

        log.Println(err)

        os.Exit(1)

    }

}

When I run that code, it does run on the web site, and the /stop will cause it to panic and end the program.

The "problem" is that this also shows up on other web sites that are on the same server!

And the /stop on the othersite.com will cause the program to panic and stop.

So I need to make this where it responds only to my web site.  And as someone above said, I do NOT have a specific ip address for the web site.  It is an ip to the server.  I believe apache takes over at that point to send the request to the correct url.

Because it is a shared host, I don't know if I can do any of the reverse proxy stuff or anything else that would effect the other sites on the server.

In another thread it was suggested to use localhost:8080 in the handlefunc.  Further discussion suggested it might need :// infront of that.

I tried this change to the above code.

 http.HandleFunc("localhost:8080/", handler)
    http.HandleFunc("localhost:8080/stop", stopHandler)
    err := http.ListenAndServe(":8080", nil)

the program ran, but it gave a 404 page not found error when I went to mysite.com:8080
same thing when I tried the /stop at the end of the url.

The same thing happened when I went to the url of another site on the server, so it is not responding only to my domain.

How do I get the server to only respond to requests for mysite.com?  Please give specific code examples, I have not been able to figure it out on my own.

Thank you,

Jim.

[Kiki Sugiaman]

When you deploy, your host is not localhost anymore. Have you tried changing "localhost:8080/" to "mysite.com:8080/"

The same thing happened when I went to the url of another site on the server, so it is not responding only to my domain.

How do I get the server to only respond to requests for mysite.com?  Please give specific code examples, I have not been able to figure it out on my own.

Thank you,

Jim.

--

[Eric Palmer]

If I'm understanding this then

x.com, y.com and z.com (some list of host names) are mapped to the same ip address. Right?

You are listening to a specific port (8080).  All requests to the ip address on the server at 8080 will go to your go program.  So for this example x.com, y.com and z.com will go to the same http server when accessing 8080.  That is because at the lower level it is just an ip and port #.  Knowledge of the host name is not at that level of tcp net listening.  What you need is http/1.1.  See below.

You can restrict what you respond to if you look at the request header and see what the request url is.  Then you can decide only to respond to that host and ignore the others. I don't know that go syntax.

Modern httpd web servers support virtual hosts (apache httpd for example) . See this post http://en.wikipedia.org/wiki/Virtual_hosting

http/1.1 protocol supports virtual hosts.  I have no idea if go supports 1.1. But I doubt it as it I am assuming it is meant to be lower level.  

I hope this helps. If I am miss reading this let us know more about the problem.

Eric

--

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/groups/opt_out.
 
 

--
KK4MWM (Ham Radio)
About Me
http://www.thingiverse.com/DaddyOh
Join the 3DPrinter Revolution
http://makerbot.com

[Jim Ellis]

Ksug,
http://mysite.com:8080/ does not work. It is looking for an up address to go with the port 8080. It is the nil that should refer to the url. But I have not figured out how to make mux work.

Eric, you summed it up real well. The thing is I need the go code to get it to work.

Thanks
Jim.

[Kiki Sugiaman]

If x.com, y.com, and z.com are mapped to the same IP address, then the server will receive all requests directed to all 3 domains.
However, my understanding is that the mux can choose to only respond to requests directed to a specific host:port, and return 404 on others.

On 6/11/2013 5:24 PM, Eric Palmer wrote:

[Matt Silverlock]

The "nil" in ListenAndServe(":8080", nil) is not meant to refer to a hostname/domain name: it is meant to refer to a set of handlers (i.e. one Go app can handle routes for many applications). Note that this is outside the scope of what you are doing and therefore don't worry about this.

The problem you are having is this:

1. Apache receives a request.

2. It directs it to port 8080 where your Go application is listening

3. Your Go application responds, and Apache serves that response.

What information we are missing:

1. Your shared host - who is it? Are you hosting this on your own Apache server, or a company?

2. Apache on this machine does not sound like it is set up correctly: it should serve requests for http://yoursite.com/ to a specific port (:8080, in your case) or FCGI socket. But not all requests.

Note that much of this is beyond the scope of Go itself—Ruby and Python applications would suffer similar problems.

[Andy Balholm]

On Tuesday, June 11, 2013 3:24:38 PM UTC-7, Eric Palmer wrote:

http/1.1 protocol supports virtual hosts.  I have no idea if go supports 1.1. But I doubt it as it I am assuming it is meant to be lower level.  

Go does support HTTP 1.1. 

[Eric Palmer]

that is good to know.

[Kiki Sugiaman]

OK, I did a little experiment to prove this. I deployed the following code:

/*====*/
package main

import (
"net/http"
)

func main() {
http.HandleFunc("godeploy.sugiaman.com:8080/", func(resp
http.ResponseWriter, req *http.Request) {
resp.Write([]byte("Hello world!"))
})
http.HandleFunc("godeploy.sugiaman.com:8080/stop", func(resp
http.ResponseWriter, req *http.Request) {
resp.Write([]byte("/stop/called"))
})
http.HandleFunc("godeploy.sugiaman.com:8080/start", func(resp
http.ResponseWriter, req *http.Request) {
resp.Write([]byte("/start/called"))
})
http.ListenAndServe(":8080", nil)
}
/*====*/

to godeploy.sugiaman.com:8080 and godeployfalse.sugiaman.com:8080 (both
resolve to 198.199.106.37) . Notice the lack of trailing "/" on "/stop"
and "/start", it makes a difference in my test.
I can confirm that requests to godeploy are answered, and requests to
godeployfalse receive 404.

Can you confirm this?

[Eric Palmer]

This is awesome.

Sent from my iPhone

[Jim Ellis]

Ksug,

I am at my grandsons ball game. I checked your links on my DROID and they worked as intended. The start&stop commands worked too on the first link.
The second link returned a 404 like it is suppose to and the start&stop commands also returned 404.
So it looks like that should do the job.

In the morning I will lead that code on my server and let you know the results.

Thank you! !!

Jim.

[Kiki Sugiaman]

Thanks for confirming it. I'll take down the server instance.

[Jim Ellis]

ksug,

I figured out why I have been having such of a hard time getting this figured out.

I started with my code that was posted above, and put in mysite.com:8080 on the 2 http.handlefunc lines before the /

I compiled and ran it on the server, and it did not work, as I was only able to get a 404 reply.  even with the /stop /start commands, same thing, 404.

I even tried it with test.mysite.com and it still would not work. (404)

So I created a new file, ksug.go with your code copied exactly from your post.  The only change I made was I replaced yoursite with mysite on the 3 handlefunc lines.

Compiled, ran, and still it did not work.  (404)

I began to experiment with different variations of "mysite".  Eventually went back to the original mysite.com:8080

I put this on the server and ran it again.

This time the url in my browser was showing mysite.com:8080/stop

I just hit the enter key and was amazed to see that IT WORKED!  I got the stop message line on the page!

so what was different?

It took me a few minutes and then I figured out that www. was not showing in the url when it works, and if www. is showing it will return the 404  So I found the reason for the problem quite by accident.

when you type in the url of mysite.com the browser will stick the www. in front of it.  And this is where it caused me the problems, because it kept returning the 404 message, not the "hello" message.

When a link is clicked on, it does not stick the www. in front of it, thus, your links that you provided yesterday worked just fine.

Sooooooooo, 

your code is a partial solution.  It shows that the go program CAN respond only to the requests for mysite.com and will return a 404 for any other site on the shared server that happens to make a request to port 8080.

But now we have the issue of how specific that line is being interpreted.  
When there is nothing infront of the / it will work for anything that is in the browsers url that is being sent to the server.

When we put in the mysite.com:8080 before the / then it works as long as there is NOTHING infront of  mysite

So, I added www. to the 3 lines where it reads www.mysite.com:8080

This improved the results, as when I typed in mysite.com into the browser it auto added the www. and I got the hello message.

Even when I typed in http://www.mysite.com:8080 in the url it removed the http part and just began the url with www. so it worked.

BUT, when I went to my droid, it's browser did http://mysite.com:8080 and I got the dreaded 404.

it appears to me that we have 3 cases.

mysite.com:8080

www.mysite.com:8080

http://mysite.com:8080

Is there a way that this can be mapped (perhaps as a variable) and put into the handlefunc line where the / or /stop can be added to it?

Thanks,

Jim.

[Matt Silverlock]

www.mysite.com and mysite.com are two different hostnames—which is why you're encountering this "issue" (aka expected behaviour).

Typically you should redirect from the root domain (mysite.com) to the www domain (www.mysite.com) for cookie & semantic reasons, but you can also do this in your Go application by setting up a handler for "mysite.com" and redirecting to www (and capturing the rest of the path, which I'll leave for you to figure out).

Note that http:// in this case doesn't matter: it's not part of the hostname and should not interfere with what you're doing here.

[Kiki Sugiaman]

Matt gave a good answer, but to add, the HandleFunc() is supposed to be
used like this:

http.HandleFunc("/", ....)

So when you are including things like the domain name to the string
pattern, you are making the uri handling more specific that it is
designed for.
In other words, things like subdomain.domain.com ("www" is technically a
subdomain, it's just a very common one) will not work, unless you handle
each. When you use "/", you can deploy to any uri containing any host
name, but you won't get domain binding.

Let us know if you are still having problems.

[Jim Ellis]

ok, first a little "house keeping".  Based on the last 2 replies, instead of the term "url" the term host name or domain name is more appropriate for the issue I am having.  So I will use either of these terms.

Matt, 

Thanks for  that answer, the "concept" is starting to become clear.  

Let me talk my way through this to see if it will help.

When "listenandserve" is called, it is telling the operating system to send internet requests to the go program.  For the ":8080" we are specifying to limit those requests to only the ones that are coming in on port 8080.  In this case it uses all requests that the operating system gets on either "localhost" or the ip address that maps to localhost.

This is why on a shared web server any of the web sites can call to port 8080 and access the program when just the "/" is used in the handlefunc.

This explains the behavior I was getting when I first got the program to run on the web site, where mysite.com:8080 and theirsite.com:8080 both got the "hello" page.

ksug showed how we can put the domain name in the handlefunc line, but it is messy, because there is a difference between the root domain and subdomains.  (www is treated as a sub domain)

It appears to me that the handlefunc is useful for a "path" that is at the end of the domain name.  

Where we use just "/start" to call a function that runs the code we want ran for the "start" page.

This makes sense, because pretty much so these "handlers" are typically used for navigation of the web site, such as when you go to a "forum" the url would be domain name/forum, so /forum is the handle to take you to the code to print out the forum for the user to see.

Earlier in this thread someone pointed to the servemux as the place to "register" the domain name.  
I even looked at the server.go source code, and in the comments it appears that this "should" be the area to list the domain name.

It appears to me that the handlefunc "registers" the handle in the servemux.  So we are right back to the "messy" stuff from above.  And I have not found a way just register the domain name by itself where the function calls can be flagged with just "/start" 

************

It seems to me that the net/http routines are missing the way to define the domain name, so that when listenandserve is called it can not only filter on the port number, but also on the domain name.

***********

IMHO it would make life a lot easier if the listenandserve routine would allow for the registration of the domain name in a simple manner.  Then the handlefunc command would work just fine for the "/start" type of declarations for additional path of the url.

As to Matt's suggestion to redirect the root domain name to www.domain name, I must not be too bright, cuz I have not figured it out.  Or at least now how to do it by adding or modifying a line in the code that ksug posted.

I just am not getting the grasp on how to get it done.

So, I am just going to use the gorilla mux routine, as they have a register domain feature, and then the way to call the declarations for the additional path.

(Perhaps this is why I did not figure it out.  I was not looking at doing a separate package that manipulates the servemux and handlefunc processes)

Perhaps after some time of looking at the gorilla code I will get it figured out..........

Jim.

[James Bardin]

On Wed, Jun 12, 2013 at 4:29 PM, Jim Ellis <jimel...@gmail.com> wrote:

When "listenandserve" is called, it is telling the operating system to send internet requests to the go program.  For the ":8080" we are specifying to limit those requests to only the ones that are coming in on port 8080.  In this case it uses all requests that the operating system gets on either "localhost" or the ip address that maps to localhost.

Don't think of it that way. ListenAndServe binds to a tcp port, so ':8080' is listing on port 8080 on in wildcard address (0.0.0.0 for ipv4), so it can accept from localhost, OR your public ip address. Plus, an ip address doesn't map to localhost, it's the other way around. Localhost is just an alias for the 127.0.0.1 ipv4 address, or the ::1 ipv6 address, and resolved locally. Using 

'mysite.com:8080' in listen and server doesn't have anything to do with "mysite.com" after that is resolved, it will be listening on your ipv4_address:8080. The operating system knows nothing about the hostname intended for the incoming packets. Your program is getting that from the Host http header.

This explains the behavior I was getting when I first got the program to run on the web site, where mysite.com:8080 andtheirsite.com:8080 both got the "hello" page.

Note that if mysite.com and theirsite.com have separate addresses, you can bind to those directly.

  

************

It seems to me that the net/http routines are missing the way to define the domain name, so that when listenandserve is called it can not only filter on the port number, but also on the domain name.

***********

Checking the host header on every request isn't needed in most situations, so you either use the builtin mux capabilities of assigning the host, write the login yourself in your handlers, or use an external library like gorilla/mux. I don't think it's an oversight that it's not directly handled in the std library.

 

As to Matt's suggestion to redirect the root domain name to www.domain name, I must not be too bright, cuz I have not figured it out.  Or at least now how to do it by adding or modifying a line in the code that ksug posted.

I just am not getting the grasp on how to get it done.

These things are easily configured in a webserver with no extra code, which is another reason you may want to drop one in front of your application. You then don't have to worry about the virtual host, and the handful of redirects or rewrites you may want.

So, I am just going to use the gorilla mux routine, as they have a register domain feature, and then the way to call the declarations for the additional path.

(Perhaps this is why I did not figure it out.  I was not looking at doing a separate package that manipulates the servemux and handlefunc processes)

Absolutely nothing wring with using an external library to gain functionality that isn't included in the standard lib. 

[Jim Ellis]

James,

ok, I was wrong with the fine details, I had it backwards as to the ip/localhost mapping.  I believe though on the "concept" we are both saying the same thing.  "The operating system knows nothing about the hostname intended for the incoming packets"

Because the go program is listening to the port, and the operating system does not know anything about hostnames, the go program is showing up on any/every domain on the server that makes a call to that port.

"Checking the host header on every request isn't needed in most situations,"

On a SHARED server, where there are multiple domains, this becomes an issue and is needed because the operating system does not know about host names.  The program needs a way to "filter" where only the correct domain name can access the program.

Concerning the redirect, you said "These things are easily configured in a webserver with no extra code, which is another reason you may want to drop one in front of your application. You then don't have to worry about the virtual host, and the handful of redirects or rewrites you may want."

Are you talking about doing a linux or apache redirect?

I was trying to figure it out using the go redirect in the net/http package.
And it would appear that it would take a bit of extra code to do it in go, which is what the gorilla mux has done.  It is a good bit of code.  

From a "casual programmer" perspective, perhaps the hostname should be a feature in the standard library.  

If/when go becomes more popular and starts being used by "the masses", many of them will want to just rent a website from a webhost and put their web site up.  So the issues I am encountering will be pretty widespread, as I believe that linux + apache is one of the more common hosting platforms, and many people will opt for the lower cost of a shared host.

So being able to put the host/domain name into the listenandserve command for the filtering would make it a lot easier to use.

Tomorrow I am going to start work on using the gorilla mux, and hopefully it goes smoothly, so at least there is that light at the end of the tunnel.

Thanks,

Jim.

[James Bardin]

On Wednesday, June 12, 2013 6:06:38 PM UTC-4, Jim Ellis wrote:

James,

ok, I was wrong with the fine details, I had it backwards as to the ip/localhost mapping.  I believe though on the "concept" we are both saying the same thing.  "The operating system knows nothing about the hostname intended for the incoming packets"

Because the go program is listening to the port, and the operating system does not know anything about hostnames, the go program is showing up on any/every domain on the server that makes a call to that port.

Exactly, but don't overlook these "fine details" as random minutia. Once you understand the concepts involved, most of these systems issues will be fairly obvious. If you just try to memorize all these facts without context, you building an incomplete picture which can lead you astray later on.

 

"Checking the host header on every request isn't needed in most situations,"

On a SHARED server, where there are multiple domains, this becomes an issue and is needed because the operating system does not know about host names.  The program needs a way to "filter" where only the correct domain name can access the program.

Concerning the redirect, you said "These things are easily configured in a webserver with no extra code, which is another reason you may want to drop one in front of your application. You then don't have to worry about the virtual host, and the handful of redirects or rewrites you may want."

Are you talking about doing a linux or apache redirect?

With any webserver (again, this isn't a function of the OS/Linux kernel). Apache is popular, but so are others like nginx.

 

I was trying to figure it out using the go redirect in the net/http package.
And it would appear that it would take a bit of extra code to do it in go, which is what the gorilla mux has done.  It is a good bit of code.  

From a "casual programmer" perspective, perhaps the hostname should be a feature in the standard library.  

If/when go becomes more popular and starts being used by "the masses", many of them will want to just rent a website from a webhost and put their web site up.  So the issues I am encountering will be pretty widespread, as I believe that linux + apache is one of the more common hosting platforms, and many people will opt for the lower cost of a shared host.

So being able to put the host/domain name into the listenandserve command for the filtering would make it a lot easier to use.

l personally don't think go is going to fill the role of "entry-level web programming language on shared hosting", but who knows. Even if it does gain in popularity in that role, it would have to be deployed behind a web server, like apache, and be accessed through a reverse-proxy or fastcgi in order to share the same ip:port. The webserver would then still be in charge of routing based on the virtual host, obviating the need to handle it in the application logic.

 

[Matt Silverlock]

>  the go program is showing up on any/every domain on the server that makes a call to that port.

Very different from what you're saying. The Go application is just handling any HTTP request that hits the port it's listening on. Because there is no logic in front of it (a web server) to filter out requests for Sites X & Y and only serve requests for Site Z (in this case, www.mysite.com). The Go program isn't so much "showing up" on those domains: those domains just end up hitting the Go application because nothing is telling them to go elsewhere (read: be served by another application).

> On a SHARED server, where there are multiple domains, this becomes an issue and is needed because the operating system does not know about host names.  The program needs a way to "filter" where only the correct domain name can access the program.

Yes, on a "shared" server, you will typically have a web server up front that parses the HTTP host header on an incoming connection and directs it to the appropriate application (PHP, Go, Python, etc.) sitting behind it. The web server is the "filter", here. The crux of your issue is that the easiest way to do this—using a web server—is not configured correctly (or at all?).

> Are you talking about doing a linux or apache redirect?

Apache is a web server. Apache can use hostnames (as they exist within a HTTP host header) to set up rules (or "filters"). Linux is an operating system that Apache can happen to run on.

> So being able to put the host/domain name into the listenandserve command for the filtering would make it a lot easier to use.

As touched on above, on a shared host, Apache handles this. The hosting provider configures Apache with the customers' domain name (usually in a heavily scripted environment) so that the customer doesn't need to, and so that their application will never see requests for hostnames other than their own (a security/trust issue).

Someone writing a PHP application (for example) should never have to worry about only accepting requests for their domain—because the web server sitting in front of their application is configured to only send them requests for their own domain. Go can work exactly the same in this regard: it's just that your hosting provider isn't doing this the right way.

Who is your hosting provider, by the way?

[Kiki Sugiaman]

Standard libraries of all programming languages only try to cater to the "lowest common denominator" of functionalities (and this is subjective) and not the various business requirements that the language's users have.

Try to work with Gorilla and post back when you're stuck. They even have their own mailing list.


On 6/12/2013 3:29 PM, Jim Ellis wrote:

....

************

It seems to me that the net/http routines are missing the way to define the domain name, so that when listenandserve is called it can not only filter on the port number, but also on the domain name.

***********

IMHO it would make life a lot easier if the listenandserve routine would allow for the registration of the domain name in a simple manner.  Then the handlefunc command would work just fine for the "/start" type of declarations for additional path of the url.

As to Matt's suggestion to redirect the root domain name to www.domain name, I must not be too bright, cuz I have not figured it out.  Or at least now how to do it by adding or modifying a line in the code that ksug posted.

I just am not getting the grasp on how to get it done.

So, I am just going to use the gorilla mux routine, as they have a register domain feature, and then the way to call the declarations for the additional path.

(Perhaps this is why I did not figure it out.  I was not looking at doing a separate package that manipulates the servemux and handlefunc processes)

Perhaps after some time of looking at the gorilla code I will get it figured out..........

Jim.

[Andrew Gerrand]

On 13 June 2013 06:29, Jim Ellis <jimel...@gmail.com> wrote:

************

It seems to me that the net/http routines are missing the way to define the domain name, so that when listenandserve is called it can not only filter on the port number, but also on the domain name.

***********

It can be accomplished with a few lines of code.
You should read/watch this: http://talks.golang.org/2012/simple.slide

Particularly the example toward the end, which is based on this: http://github.com/nf/webfront

Andrew

[Kyle Lemons]

Here is my suggestion for how to structure such a program:

domainMux := http.NewServeMux()

coolSite := http.NewServeMux()

coolSite.Handle("/", coolSiteRoot)

coolSite.Handle("/cool", coolHandler)

...

domainMux.Handle("domain.com/", coolSite)

boringDomain := http.NewServeMux()

boringDomain.Handle("/", http.NotFound)

boringDomain.Handle("/secret", boring)

domainMux.Handle("boring.com/", boringDomain)

domainMux.Handle("/", func(w http.ResponseWriter, r *http.Request) {

  // look for domain redirects

  // if you find one, do an http.Redirect

  return http.NotFound(w, r)

})

This gives you:

- simple routes for each domain (these can be even done in their own packages) that don't have to have domain prefixes

- one handler that handles each domain

- one place to have logic for redirecting e.g. www to . or vice versa.

HTH

Jim.

--

[Jim Ellis]

@Matt,

"because the web server sitting in front of their application is configured to only send them requests for their own domain. Go can work exactly the same in this regard: it's just that your hosting provider isn't doing this the right way.

Who is your hosting provider, by the way?"

active-server.com is the host I have been using for many years.   The current sites I run have html, php and use a mysql database.

For the "regular" web site config it has worked just fine, mysite.com and theirsite.com have never had any conflicts.  And the guy that runs the host has been pretty helpful where in the past I have never had to worry about any "network admin" type of issues.

As to changes to the apache configuration, he is saying that is beyond the scope of regular support, and the per hour fee is a bit stiff.  He has told me I can make the changes myself (once I figure out what files to change.....).  He suggested making sure the files were backed up before making a change, which I would say is a good suggestion.

Today was a busy day for me work wise.  I only had a limited amount of time to mess with my little go project.  And some of that time was taken with updating to the new go release and updating goxc for the cross compiling.

After looking at Andrew's reply I figured I would try that first.  It looks like it is a lot more direct and less code than the gorilla interface, and coming from one of the people designing the language, I would be a fool not to give his suggestion a very serious look.

I also viewed the video.  The start of the webmain section is around the 32 minute mark of the video.

I took his code put exactly as it on gethub, the only change was in the json file I put in mysite.com in place of example.com, and for the serve path I added /html to it to match the actual path on my server.

Compiled and put the binary file and the json file on the web site.

The code calls for the program to listen to port 80.  When I ran it, I was given the error message that I did not have permission.

So I changed the code to listen to port 8080 and the json file to redirect to 8085.

It ran, and I got a page that listed all of the files in the html directory.

but I noticed I had both lines in the json file looking at mysite.com

I did not have time to do much else with it, so tomorrow I will look into making some changes to the host & serve in the json file and also adding in a few handlefunc commands for menu navigation ( /start /this /that, etc.... ) to the code to produce a page and see how it goes.

--- I will admit that I am not overly enthused about the reply I got on taking care of the apache settings.  I might wind up doing the dev on port 8080 and after reviewing the results of a more developed app consider looking at a different web host.

----------------------------------------------------------------------

@ ksug,

 

lol, "post back when you're stuck"  :)

----------------------------------------------------------------------

@Andrew,

A big Thank You for the links to the video and the webfront example.

You are good in those videos, I was following along and it makes a lot of sense.  
I believe I had already seen that video once a month ago when I first started looking at go.  I did not think to make note about the example that was used in it.

I believe that the issue of sites on shared hosts will be an issue that will show up more and more as go gains users.  So I trust that you don't mind that I will include those links in the guide that I am working on to show the steps that I have used to get a go program developed on a win7 pc, cross compiled and ran on a unix/apache server.

Your demo of that code convinces me that if I still have problems then it is a server issue. 

---------------------------------------------------------------------- 

@Kyle,

If I understand where you are going with your code, it is registering each domain, and for the ones that are not "mine" it is returning a "not found" response.

The problem is that on the shared server I would not know of all of the domains that are on it.

If I am the only person using the server, and it is just for my web sites, then yes, this would work as it would be able to filter out the "boring" domains that should not use the go program for mysite.com.

Thanks all,

Jim.

[Kyle Lemons]

Ah, I must have missed that part of your request.

It is not possible for multiple web servers to directly listen on a single port.  Your Go server must handle all of the requests on whatever port it's listening on.  Instead of returning 404 for the other domains, you could reverse-proxy to Apache or do a redirect to the port that serves them.  You could also do the opposite, and have apache or nginx rproxy or redirect to your Go app for only the domains it presents.

 

Thanks all,

[Andrew Gerrand]

On 14 June 2013 06:32, Jim Ellis <jimel...@gmail.com> wrote:

@Andrew,

A big Thank You for the links to the video and the webfront example.

You are good in those videos, I was following along and it makes a lot of sense.  
I believe I had already seen that video once a month ago when I first started looking at go.  I did not think to make note about the example that was used in it.

I believe that the issue of sites on shared hosts will be an issue that will show up more and more as go gains users.  So I trust that you don't mind that I will include those links in the guide that I am working on to show the steps that I have used to get a go program developed on a win7 pc, cross compiled and ran on a unix/apache server.

Glad to hear it is helpful!. And of course, you can reference it wherever you wish.

Cheers,

Andrew

[Jim Ellis]

I definitely have server permission issues.  I put just the "forward" line in the json file to activate the reverse proxy.
I was told permission denied to do the redirect from port 80.  So I tried it where the incoming port was 1234 and the redirect was to 8080.  The connection was refused by the server.

So, unless I figure out what config files need to be edited on the apache server, and what the change is that would be needed, I have to use the listenandserve with :8080 in it.  I can "live" with this for development.  To go the web site a "real" one though either I will need to get that apache server configured to allow the redirect from port 80 to 8080, or I will need to go to a different host.  So while I am doing the development I will be looking into both options and make a decision that is best for me at that time.

----------------------------------------

I mentioned several times that I have been working on a guide where I took notes of what I had to do to reach this point.  I want to post those notes here as a "rough draft".  I would appreciate any feedback on them, and once the feedback is worked into the notes I will post them as a "guide", and perhaps they could also be posted to the wiki to try to help other new people that are not network/apache guru's.  

Also, I want to thank everyone for having some patience with me as I have been trying to get this figured out how to get the program to run on the web server.  I feel comfortable that I now have the knowledge to get the program to work as a web site on a server that has the permissions set correctly.

------------------------------------

Guide for using Win7 pc to create a web site to run on a linux/apache web server.  (DRAFT)

My experience in getting a go program to run on as a web site.

I am using Win7 for my development platform, and my web site is on a hosted (shared) apache web server.   (I happen to have a second site on that same server, so I have been able to test the "shared" issues.

#1.  Install go on pc.   ( http://golang.org/doc/install )

#2.  Install tools.   Most of these instructions are from a post by Aleksey Levykh in the following thread in the golang-nuts group.  I have added a few comments based on my experience in getting this set up.

( https://groups.google.com/forum/?fromgroups#!searchin/golang-nuts/must$20be$20bootstrapped$20using$20make.bash/golang-nuts/oRf-vgDjBLI/uE4IOE2HkowJ )

Download and install needed for you "get tools" https://code.google.com/p/go-wiki/wiki/GoGetTools (hg and git - important, usually)

** reboot after each (hg & git).  Both modify the path so the reboot is needed to activate it.

Both are used in the command prompt.

Download and install MinGW http://tdm-gcc.tdragon.net/ [This is unofficial builds support 32/64 bits Windows] !Don't forget set PATH variables! 

path should be part of the 64 bit install routine.  -- reboot

Make sure GOROOT and GOPATH are set.  (GOBIN may also need to be set.)

Control Panel --> System --> Advanced system settings

Advanced tab --> Environment Variables

System variables section:

the golang install should have set the GOROOT path, make sure it and GOPATH are listed.

If not, click on "new" the vaiable is GOROOT and the value is C:\Go\

For GOPATH you can create a sub directory such as go\gocode and use that as the value, so that the go get will install the code in a location you can easily find.   I wanted to segrigate 3rd party code from the go source packages and my own packages.

-- reboot so the variables will be loaded.

Install goxc:  command line prompt >:   go get github.com/laher/goxc

Build toolchains for all platforms:

move the goxc.exe from the gocode bin directory to the c:\go\bin directory 

rutn  >:  goxc -t   to build the toolchains.

** NOTE: this command needs to be ran when go is updated.  The change from go 1.1 to 1.1.1 resulted in the addition of a new package.  The cross compile was not able to compile a project until the goxc -t was reran to include that new package.

Cross compiling works well, but be aware there is an issue with pacakages that use cgo(read last message from Dobrosław Żybort)

3.  Install IDE.

You can use just a text editor, such as notepad or araneae.  But most programmers, especially those from a windows environment are more comfortable with an IDE.

Before installing the cross-compiling stuff I first used Eclipse as an IDE for go.  

http://code.google.com/p/goclipse/

I liked how it worked as the first IDE I tried out for Go.  

When I started looking into the cross-compiling though, I found that LiteIDE has the ability to pick the platform you want to compile to.

https://code.google.com/p/golangide/downloads/list

*** The one issue I have is that after loading the cross-compiling instructions on this page, eclipse will not build a go program now.  

4.  Build a "web app".

CODE:

package main

import (

"log"

"net/http"

"os"

)

const resp = `<html>

    <head>

        <title>Simple Web App</title>

    </head>

    <body>

        <h1>Simple Web App</h1>

        <p>Hello Jim!</p>

    </body>

</html>`

func handler(w http.ResponseWriter, r *http.Request) {

w.Write([]byte(resp)) //shows the hello jim message for root domain name

w.Write([]byte("/root called"))

}

func startHandler(w http.ResponseWriter, r *http.Request) {

w.Write([]byte("/start called" + title))

}

func stopHandler(w http.ResponseWriter, r *http.Request) {

w.Write([]byte("/stop called"))

go gopanic() //calls the panic function to end the listenandserve

}

func gopanic() { // very ugly way to abort the listenandserve

panic("stop request called")

}

func main() {

http.HandleFunc("/", handler)

http.HandleFunc("/stop", stopHandler)

http.HandleFunc("/start", startHandler)

err := http.ListenAndServe(":8080", nil)

if err != nil {

log.Println(err)

os.Exit(1)

}

}

-----------------------------------------------

a).  Notice that this specifies err := http.ListenAndServe(":8080", nil)

This is so you can test it on your  pc.  You open your browser and enter localhost:8080 

When you are ready to put this on the apache server.  This will listen to any and all requests on port 8080 on the server.

Note: if you are on a shared web host, based on the apache configuration EVERY web site on that server will be able to access your web app!  Such as someone with a site on that same server, if they go to theirsite.com:8080 will see the page your web app creates. 

Andrew Gerrand posted 2 links on how to "filter" the requests to where only your domain will respond to the requests.

The first link is the slide show and video link to a presentation he gave.  The slides are near the end.  In the video he begins talking about the webfront example at the 32 minute mark.

The second link is the actual go code for the webfront example.

Slides/video link: http://talks.golang.org/2012/simple.slide

which is based on this: http://github.com/nf/webfront

The one thing you may want to do is add the HandleFunc lines to the main func, and add the handler functions to the webfront code to have it return a page based on the path following the domain name.

b.)  gopanic - this is a crude way to cause the program to end.  It sends a panic error message to the program to cause it to "crash".  But at this time this is the most effecient way I have seen to terminate the listenandserve process.  The gopanic routine would need some work to "protect" it from anyone that happens to discover the /stop is a command to shut down the site.  This is just a quick way to end the program while you are developing it.  For a full time web site you would want to remove this from the program to prevent it from being terminated.

5.  Build the program for the server platform.  For my server this is with the linux 32 selection.

6.  FTP the program to the website.  

*** Right now I am just putting it in the "root" directory of the website, where the index.html page would go.  (  /var/www/html directory on the linux box.)

a.)  CHMOD the file to make sure it can be executed.  The ftp client I use allows me to right click the file and it has a check mark box by "execute".  I check all 3 to allow it to run.

7.  I am using Putty ( http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html ) for my ssh client.  Install or ensure you have ssh client to use.

8.  Log into the server.  Make sure your login has admin privliges.  

cd /var/www/html   (this is the path for my server.  Some servers could use just /var/www)

./program_name &

The "&" allows it to run in background mode.

 If there are any errors they will be listed and the program will not run.  You will need to fix the problems.

When it runs take note of the process id that is created.   This id is needed to KILL the progrom via the ssh client.

Exit to exit the ssh client.

When you go to www.yoursite.com:8080 the page should be shown. 

add /start to see the "start page" that is returned.

Add /stop to the end of the url and it should stop the program.

If not, you can log back into the ssh client.  The command ps -A will list all processes.  Note the process id for the program.

Kill processid is the command to terminate the process.

------------------------------------------------ [end draft]

Thanks all,

Jim. 

[James Bardin]

I you have access to the apache config, you would be better served by proxying your domain from port 80 to 8080, rather than setting up a redirect. If you add any html pages, the browsers are always going to assume the incorrect port if you don't specify it directly.

On Fri, Jun 14, 2013 at 12:43 PM, Jim Ellis <jimel...@gmail.com> wrote:

8.  Log into the server.  Make sure your login has admin privliges.  

cd /var/www/html   (this is the path for my server.  Some servers could use just /var/www)

./program_name &

I didn't read everything in detail, and I know I've already said this, but you really *really* need to brush up on some systems background if you're going to be deploying a webapp like this, especially if you are instructing others how to do so.

That directory is probably in what apache calls the DocumentRoot. Do no put your executable there, as it will be accessible from the web, and could lead to other problems if the server is misconfigured, or you just don't want anyone to get the raw executable. Put it somewhere outside the view of the webserver.

Simply backgrounding a process is the worst way to run a service, if it even continues to run when the shel exits (it would have to ignore SIGHUP to do so). For testing you can run it in something like screen or tmux, but you would want something to manage the process eventually.

[Kyle Lemons]

On Fri, Jun 14, 2013 at 9:43 AM, Jim Ellis <jimel...@gmail.com> wrote:

I definitely have server permission issues.  I put just the "forward" line in the json file to activate the reverse proxy.
I was told permission denied to do the redirect from port 80.  So I tried it where the incoming port was 1234 and the redirect was to 8080.  The connection was refused by the server.

Only root can listen on port 80.  The usual solution to this is to listen as root and then drop privs to whatever user (e.g. apache, nobody, etc) afterward.

 

Jim. 

[Kyle Lemons]

On Fri, Jun 14, 2013 at 10:16 AM, Kyle Lemons <kev...@google.com> wrote:

On Fri, Jun 14, 2013 at 9:43 AM, Jim Ellis <jimel...@gmail.com> wrote:

I definitely have server permission issues.  I put just the "forward" line in the json file to activate the reverse proxy.
I was told permission denied to do the redirect from port 80.  So I tried it where the incoming port was 1234 and the redirect was to 8080.  The connection was refused by the server.

Only root can listen on port 80.  The usual solution to this is to listen as root and then drop privs to whatever user (e.g. apache, nobody, etc) afterward.

... well, or to use inetd or something that will listen for you and hand you file descriptors.

[Kiki Sugiaman]

Hi Jim,

I want to go on tangent here a little bit and present an alternative, since you are at a point where you're considering  going for a different host.

<tangent>
You are probably better off going for VPS, or better yet, cloud hosting (which is basically a VPS you can bring up and take down at any moment and you are billed hourly).
An easy to use one: https://www.digitalocean.com/, look at their pricing. It might even be cheaper than your shared hosting.

Yes, you have to do your own Linux sysadmin but think about it: even with your shared hosting you still have to daemonize and monitor your Go app and worse, perform these port and domain acrobats. Your host is also not willing to configure your front-end server for you, and I assume you don't know whether or not you have access to the configuration files.

If you go this way, you will have your own "machine" (a virtual one) with its own IP address just for yourself. You can skip all the port and domain binding work, and only put up a front-end server when you have a reason to.

To learn sysadmin quickly, force yourself to develop on Linux. Ubuntu is pretty easy to use. Install something like Vmware Player or Virtualbox on top of your Windows so you don't have to waste time configuring dual booting etc.
</tangent>

On 6/14/2013 11:43 AM, Jim Ellis wrote:

I definitely have server permission issues.  I put just the "forward" line in the json file to activate the reverse proxy.
I was told permission denied to do the redirect from port 80.  So I tried it where the incoming port was 1234 and the redirect was to 8080.  The connection was refused by the server.

So, unless I figure out what config files need to be edited on the apache server, and what the change is that would be needed, I have to use the listenandserve with :8080 in it.  I can "live" with this for development.  To go the web site a "real" one though either I will need to get that apache server configured to allow the redirect from port 80 to 8080, or I will need to go to a different host.  So while I am doing the development I will be looking into both options and make a decision that is best for me at that time.

Port 80 is probably used by Apache itself. If it is, there is nothing you can do in your Go app to do the redirection.
If it's not, you still need root privilege to listen on any port # < 1024.

[Jim Ellis]

@James,

"I you have access to the apache config, you would be better served by proxying your domain from port 80 to 8080, rather than setting up a redirect. If you add any html pages, the browsers are always going to assume the incorrect port if you don't specify it directly."

It is clear in this thread that I lack a lot of knowledge about network systems admin.  So, I want to make sure I understand what you are saying, also I believe it ties in with Ksug's reply.

 

I take it that it would be best to let apache listen to port 80 and when a request comes in for "mysite.com" send it to port 8080.

My go program will be listening to port 8080 and will then process the incoming request.  If it matches a handle I have set up in the program, then the go program will return the "page" results.  If it is not a handle I have set up is an issue I have learned about yet.  I "guess" that there are 2 possibilities for this.

#1. the request "passes through" and if there is an html page the apache server returns it to the users web browser.

#2. I will need to put some code into my program that if the requested url/path is not one of my handles, to check for the specific html page (or an index.html page) and return it as the result.

"That directory is probably in what apache calls the DocumentRoot. Do no put your executable there, as it will be accessible from the web, and could lead to other problems if the server is misconfigured, or you just don't want anyone to get the raw executable. Put it somewhere outside the view of the webserver."

That pertains to #6 of the guide.

I had asked about this earlier in the thread, and the answers were more of a "you can" than "this would be best".

I appreciate you giving me a "this would be best" answer with the explanation of why.

I will change step 6 to use /var/goprg as an example path.  

I believe a note would be needed that in the go program the path will need to be paid attention to when it comes to uploading and downloading files via the browser.

"Simply backgrounding a process is the worst way to run a service, if it even continues to run when the shel exits (it would have to ignore SIGHUP to do so). For testing you can run it in something like screen or tmux, but you would want something to manage the process eventually."

Yes, as a "permanent" web site I agree with you.  For the stage I am at right now, the backgrounding is a good way to run it for testing as it is in development.

On the server I am using I can exit the ssh client and the go program will continue to run.

Your comment would be a good one to add because it sounds like on some servers that the program would be closed when the ssh client is exited.

The guy from the host I am using said that when I am ready to have the program run full time to add the command to the rc.local file so it will be started on the server boot up.

------------------------------------------------------

@Kyle,

I "think" that my comments to the reply from James also apply to your reply.

-----------------------------------------------------

@ksug,

Thanks for the reply and info about port 80.  I remember that there is a thread in this group on hosts, and I will add your link to that list.

About learning sysadmin.  One issue I would face is that during the day I need to have a windows program running at all times for my work.  So I would have to see if that vmware player would run in a window without interfering with my work stuff.

One question this brings up about switching to a different server.  Why not switch to a windows server?

Since I am developing on a win7 pc, I would not have a cross compile issue, I would just compile to run on a win64, and once the server ports are configured to work with the go program, I would not need to worry about sysadmin issues.

Why would using a linux or ngnx server be better?

[Kiki Sugiaman]

On 6/17/2013 11:05 AM, Jim Ellis wrote:
> ....

> @ksug,
>
> Thanks for the reply and info about port 80. I remember that there is
> a thread in this group on hosts, and I will add your link to that list.
>
> About learning sysadmin. One issue I would face is that during the
> day I need to have a windows program running at all times for my work.
> So I would have to see if that vmware player would run in a window
> without interfering with my work stuff.
>
> One question this brings up about switching to a different server.
> Why not switch to a windows server?

Well, there is a larger number of free, more stable tools on the Linux
side. But if you don't mind paying for a Windows Server license (and
other necessary tools down the road when you need them), Go is pretty
stable on Windows so I don't think that there will be a problem with
choosing Windows. I just thought that since we've been discussing Linux
deployment in this thread, Windows deployment isn't being considered.

> Since I am developing on a win7 pc, I would not have a cross compile
> issue, I would just compile to run on a win64, and once the server
> ports are configured to work with the go program, I would not need to
> worry about sysadmin issues.
>
> Why would using a linux or ngnx server be better?

Basically, Nginx has a better concurrency model than Apache that it
won't become a bottleneck in your stack when you're serving a large
number of concurrent requests. But I suggest to worry about this later
when you're actually serving a large number of simultaneous requests, as
switching front-end server is easy to do.

[James Bardin]

On Monday, June 17, 2013 12:05:24 PM UTC-4, Jim Ellis wrote:

@James,

"I you have access to the apache config, you would be better served by proxying your domain from port 80 to 8080, rather than setting up a redirect. If you add any html pages, the browsers are always going to assume the incorrect port if you don't specify it directly."

It is clear in this thread that I lack a lot of knowledge about network systems admin.  So, I want to make sure I understand what you are saying, also I believe it ties in with Ksug's reply.

 

I take it that it would be best to let apache listen to port 80 and when a request comes in for "mysite.com" send it to port 8080.

My go program will be listening to port 8080 and will then process the incoming request.  If it matches a handle I have set up in the program, then the go program will return the "page" results.  If it is not a handle I have set up is an issue I have learned about yet.  I "guess" that there are 2 possibilities for this.

#1. the request "passes through" and if there is an html page the apache server returns it to the users web browser.

#2. I will need to put some code into my program that if the requested url/path is not one of my handles, to check for the specific html page (or an index.html page) and return it as the result.

Exactly. #1 is usually preferable, since the webserver already has the ability to return html pages efficiently, and has the ability to be very flexible based on configuration,

 

"That directory is probably in what apache calls the DocumentRoot. Do no put your executable there, as it will be accessible from the web, and could lead to other problems if the server is misconfigured, or you just don't want anyone to get the raw executable. Put it somewhere outside the view of the webserver."

That pertains to #6 of the guide.

I had asked about this earlier in the thread, and the answers were more of a "you can" than "this would be best".

I appreciate you giving me a "this would be best" answer with the explanation of why.

I will change step 6 to use /var/goprg as an example path.  

I believe a note would be needed that in the go program the path will need to be paid attention to when it comes to uploading and downloading files via the browser.

"Simply backgrounding a process is the worst way to run a service, if it even continues to run when the shel exits (it would have to ignore SIGHUP to do so). For testing you can run it in something like screen or tmux, but you would want something to manage the process eventually."

Yes, as a "permanent" web site I agree with you.  For the stage I am at right now, the backgrounding is a good way to run it for testing as it is in development.

On the server I am using I can exit the ssh client and the go program will continue to run.

Your comment would be a good one to add because it sounds like on some servers that the program would be closed when the ssh client is exited.

Yes, I forgot that bash is often configured with "huponexit" to be false (actually seems to be a common default, but I spent years on systems that have this set to true). This prevents your process from getting killed when the shell exits, but it's bad form to rely on, and you don't want orphaned processes that you forgot about mucking things up. You also need to make sure your stdout and stderr are redirected somewhere, because you will want the output at some point (e.g. a crash or stacktrace). For testing, a multiplexer like "screen" or "tmux" is even more convenient, since you can reattach to the same shell. In the end, running the process under some management, be it upstart, systemd, init, etc. will save you many headaches.

The guy from the host I am using said that when I am ready to have the program run full time to add the command to the rc.local file so it will be started on the server boot up.

Yes, this is a basic way of starting it via init. You should flesh it out a little more though, so you know what the state of the process is if you need to stop, or restart it, and prevent multiple copies from trying to run at the same time.

[Kyle Lemons]

On Mon, Jun 17, 2013 at 9:05 AM, Jim Ellis <jimel...@gmail.com> wrote:

@James,

"I you have access to the apache config, you would be better served by proxying your domain from port 80 to 8080, rather than setting up a redirect. If you add any html pages, the browsers are always going to assume the incorrect port if you don't specify it directly."

It is clear in this thread that I lack a lot of knowledge about network systems admin.  So, I want to make sure I understand what you are saying, also I believe it ties in with Ksug's reply.

 

I take it that it would be best to let apache listen to port 80 and when a request comes in for "mysite.com" send it to port 8080.

My go program will be listening to port 8080 and will then process the incoming request.  If it matches a handle I have set up in the program, then the go program will return the "page" results.  If it is not a handle I have set up is an issue I have learned about yet.  I "guess" that there are 2 possibilities for this.

#1. the request "passes through" and if there is an html page the apache server returns it to the users web browser.

You can tell Apache to only redirect for specific paths.  You can't make the Go one somehow let apache know that it should fall back (unless there's something new).

 

#2. I will need to put some code into my program that if the requested url/path is not one of my handles, to check for the specific html page (or an index.html page) and return it as the result.

You have to handle every request you get.  You can serve a 404, but I wouldn't recommend duplicating Apache's logic.

 

"That directory is probably in what apache calls the DocumentRoot. Do no put your executable there, as it will be accessible from the web, and could lead to other problems if the server is misconfigured, or you just don't want anyone to get the raw executable. Put it somewhere outside the view of the webserver."

That pertains to #6 of the guide.

I had asked about this earlier in the thread, and the answers were more of a "you can" than "this would be best".

I appreciate you giving me a "this would be best" answer with the explanation of why.

I will change step 6 to use /var/goprg as an example path.  

I believe a note would be needed that in the go program the path will need to be paid attention to when it comes to uploading and downloading files via the browser.

"Simply backgrounding a process is the worst way to run a service, if it even continues to run when the shel exits (it would have to ignore SIGHUP to do so). For testing you can run it in something like screen or tmux, but you would want something to manage the process eventually."

Yes, as a "permanent" web site I agree with you.  For the stage I am at right now, the backgrounding is a good way to run it for testing as it is in development.

On the server I am using I can exit the ssh client and the go program will continue to run.

Your comment would be a good one to add because it sounds like on some servers that the program would be closed when the ssh client is exited.

The guy from the host I am using said that when I am ready to have the program run full time to add the command to the rc.local file so it will be started on the server boot up.

------------------------------------------------------

@Kyle,

I "think" that my comments to the reply from James also apply to your reply.

-----------------------------------------------------

@ksug,

Thanks for the reply and info about port 80.  I remember that there is a thread in this group on hosts, and I will add your link to that list.

About learning sysadmin.  One issue I would face is that during the day I need to have a windows program running at all times for my work.  So I would have to see if that vmware player would run in a window without interfering with my work stuff.

One question this brings up about switching to a different server.  Why not switch to a windows server?

Since I am developing on a win7 pc, I would not have a cross compile issue, I would just compile to run on a win64, and once the server ports are configured to work with the go program, I would not need to worry about sysadmin issues.

Why would using a linux or ngnx server be better?

--

[Sébastien Ménard]

I'm agree, serve a 404 error on a not found handler is a normal behavior, and SEO compliant. Simply handle this in your app, and serve a dedicated page with an explanation and a link to the homepage, with 404 headers.

[Brad Fitzpatrick]

On Fri, Jun 14, 2013 at 10:16 AM, Kyle Lemons <kev...@google.com> wrote:

On Fri, Jun 14, 2013 at 9:43 AM, Jim Ellis <jimel...@gmail.com> wrote:

I definitely have server permission issues.  I put just the "forward" line in the json file to activate the reverse proxy.
I was told permission denied to do the redirect from port 80.  So I tried it where the incoming port was 1234 and the redirect was to 8080.  The connection was refused by the server.

Only root can listen on port 80.  The usual solution to this is to listen as root and then drop privs to whatever user (e.g. apache, nobody, etc) afterward.

You don't need to be root on Linux. You just need the CAP_BIND capability, which root has.