Sign inDemoInstall

Package Overview
File Explorer

Install Socket

Detect and block malicious and high-risk dependencies


Package servefiles provides a static asset handler for serving files such as images, stylesheets and javascript code. This is an enhancement to the standard net/http ServeFiles, which is used internally. Care is taken to set headers such that the assets will be efficiently cached by browsers and proxies. Assets is an http.Handler and can be used alongside your other handlers. The Assets handler serves gzipped content when the browser indicates it can accept it. But it does not gzip anything on-the-fly. Nor does it create any gzipped files for you. During the preparation of your web assets, all text files (CSS, JS etc) should be accompanied by their gzipped equivalent; your build process will need to do this. The Assets handler will first look for the gzipped file, which it will serve if present. Otherwise it will serve the 'normal' file. This has many benefits: fewer bytes are read from the disk, a smaller memory footprint is needed in the server, less data copying happens, fewer bytes are sent across the network, etc. You should not attempt to gzip already-compressed files, such as PNG, JPEG, SVGZ, etc. Very small files (e.g. less than 1kb) gain little from compression because they may be small enough to fit within a single TCP packet, so don't bother with them. (They might even grow in size when gzipped.) The Assets handler sets 'Etag' headers for the responses of the assets it finds. Modern browsers need this: they are then able to send conditional requests that very often shrink responses to a simple 304 Not Modified. This improves the experience for users and leaves your server free to do more of other things. The Etag value is calculated from the file size and modification timestamp, a commonly used approach. Strong or weak tags are used for plain or gzipped files respectively (the reason is that a given file can be compressed with different levels of compression, a weak Etag indicates there is not a strict match for the file's content). For further information see RFC9110 To go even further, the 'far-future' technique can and should often be used. Set a long expiry time, e.g. ten years via `time.Hour * 24 * 365 * 10`. Browsers will cache such assets and not make requests for them for the next ten years (or whatever). Not even conditional requests are made. There is clearly a big benefit in page load times after the first visit. No in-memory caching is performed server-side. This is needed less due to far-future caching being supported, but might be added in future. For further information see RFC9111 The Assets handler can optionally strip some path segments from the URL before selecting the asset to be served. This means, for example, that the URL can map to the asset files without the /e3b1cf/ segment. The benefit of this is that you can use a unique number or hash in that segment (chosen for example each time your server starts). Each time that number changes, browsers will see the asset files as being new, and they will later drop old versions from their cache regardless of their ten-year lifespan. So you get the far-future lifespan combined with being able to push out changed assets as often as you need to. To serve files with a ten-year expiry, this creates a suitably-configured handler: The first parameter names the local directory that holds the asset files. It can be absolute or relative to the directory in which the server process is started. Notice here the StripOff parameter is 1, so the first segment of the URL path gets discarded. A larger number is permitted. The WithMaxAge parameter is the maximum age to be specified in the cache-control headers. It can be any duration from zero upwards.

Version published




GoDoc Build Status Coverage Status Go Report Card Issues

Serve static files from a Go http server, including performance-enhancing features.

  • Based on the standard net/http ServeFiles, with gzip/brotli and cache performance enhancements.

Please see the GoDoc for more.


go get -u


User agents can cache responses. This http server enables easy support for two such mechanisms:

  • Conditional requests (using etags) allow the response to be sent only when it has changed
  • Cache-Control max-age response headers allow the user agent to cache entities until some expiry time.

Note that conditional requests RFC9110 and max-age caching (RFC9111) can work together as required. Conditional requests still require network round trips, whereas caching removes all network round-trips until the entities reach their expiry time.

Echo Adapter

Sub-package echo_adapter provides integration hooks into the Echo web framework. This makes it easy for Echo code to use this asset handler also: see the example in the sub-package for more info.

Gin Adapter

Sub-package gin_adapter provides integration hooks into the Gin web framework. This makes it easy for Gin code to use this asset handler also: see the example in the sub-package for more info.


Version 3 brings Go module support. Also, brotli encoding is supported alongside gzip encoding. Brotli now has widespread implementation in most browsers. You can compress your textual assets (including Javascript, CSS, HTML, SVG etc) using Brotli and/or Gzip as part of your build pipeline, uploading both the original and compressed files to your production server's asset directories. Brotli compression takes longer than Gzip but produces more compact files. Compression is, of course, optional.

Earlier versions

Earlier versions do not support Go modules, nor brotli encoding, although gzip encoding is supported.


This library has been in reliable production use for some time. Versioning follows the well-known semantic version pattern.




Last updated on 13 Dec 2023

Did you know?

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.


Related posts

SocketSocket SOC 2 Logo


  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap

Stay in touch

Get open source security insights delivered straight into your inbox.

  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc