Http Handler to produce static content

142 views
Skip to first unread message

Tong Sun

unread,
May 19, 2019, 9:56:38 AM5/19/19
to golang-nuts
Hi, 

How to have http.Handle / http.HandleFunc to produce static content that browser will use their caches without downloading every time? 

For a simplest http.HandleFunc, like the following, 

func sayHello(w http.ResponseWriter, r *http.Request) {
   message
:= "Hello "

   w
.Write([]byte(message))
}



Thet HTTP Header it produce is:

HTTP/1.1 200 OK
Date: Sun, 19 May 2019 13:46:32 GMT
Content-Length: 6
Content-Type: text/plain; charset=utf-8

I.e., the "Date:" part is changing all the time, even if I've added a "last-modified" Header field. 

What's the solution? Thx



Tong Sun

unread,
May 19, 2019, 10:03:40 AM5/19/19
to satyendra singh, golang-nuts
Sorry I don't quite understand -- my go application IS my webserver.

Are you saying Go net/http is not capable of doing what I'm asking?

On Sun, May 19, 2019 at 9:59 AM satyendra singh
<satyendra...@gmail.com> wrote:
>
> Hi Tong,
> You can use a webserver between browser and your go application which will take care of header modification for browser caching.
>
> Thanks and regards,
> Satyendra

Tamás Gulácsi

unread,
May 19, 2019, 10:51:59 AM5/19/19
to golang-nuts
Yust set the headers you want, with w.Header().Set, before any Write.
For example Set("Cache-Control", "public, max-age=31536000")

Tamás Gulácsi

unread,
May 19, 2019, 10:54:25 AM5/19/19
to golang-nuts
ETag and Last-Modified are just to allow the browser to decide with a HEAD request, whether GET the whole resource.

satyendra singh

unread,
May 19, 2019, 1:48:32 PM5/19/19
to Tong Sun, golang-nuts
Hi Tong,
You can use a webserver between browser and your go application which will take care of header modification for browser caching.

Thanks and regards,
Satyendra

On Sun, 19 May, 2019, 7:26 PM Tong Sun, <sunto...@gmail.com> wrote:
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f2adf5e4-5486-4bbe-9860-a6639a1142e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

satyendra singh

unread,
May 19, 2019, 1:48:39 PM5/19/19
to Tong Sun, golang-nuts
No what I have said is the enterprise or standard way of doing it.the functionality you are looking for is not specific to any programming language. It is with the http headrers which is standard across all platforms.
But if you really want to do in your app you need to cache-control header in your go response.
Read more about http cache-control header you will know.

Thanks and regards,
Satyendra

Tong Sun

unread,
May 19, 2019, 2:03:54 PM5/19/19
to Tamás Gulácsi, golang-nuts
Thanks a lot Tamás! That's very clear & helpful!

Tyler Compton

unread,
May 20, 2019, 1:08:14 PM5/20/19
to Tong Sun, golang-nuts
Sorry I don't quite understand -- my go application IS my webserver.

This is a topic that has confused me in the past. In the simple case where you build a Go executable and get requests from it directly, your Go application *is* your web server. However, it's common in industry to put a system like nginx in front of your Go executable that takes care of serving static content like images, JavaScript, CSS, and so on to the user without consulting your Go application at all. Then, when this web server gets a request on and endpoint that it doesn't know how to serve, like an API call, it will forward that request to your Go application.

With a setup like this, you're able to concentrate on writing business logic in Go and configure caching and static resource management elsewhere. In these cases, the application in front of your Go application is the "web server" because it is in charge of directly serving resources to the client. Your Go application might be called the "web application" because it is in charge of doing application-specific tasks. It isn't strictly necessary to adopt this format just to cache static resources, but if your needs become more complicated in the future it might be something worth considering :)
 
--
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.

Amnon Baron Cohen

unread,
May 20, 2019, 5:30:31 PM5/20/19
to golang-nuts
When web-apps are implemented in scripting languages which suffer from poor performance,
it is common practice to proxy them behind a "real" web server such as nginx, and offload SSL
termination, caching, handling of static components, etc to it.
In Go http.ListenAndServe is an industrial strength web server, capable of gracefully handling high request 
rates, large numbers of simultaneous connections, http2 etc. So your Go App may as well be the web server.
You are, or course, at liberty to proxy your web app behind nginx etc, like the Python and Ruby folk.
But why add extra moving parts, extra configuration and extra complexity to your deployment stack?
To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages