Release 4.0.1

What's was fixed?

• Updated docs
• Updates custom context example for simplicity
• Updated benchmarks with go1.9.2

Release 4.0.0

What's changed?

• Corrected a bug with the Group middleware see #17
• Split out Group function for clarity into:
  • Group - retains existing middleware
  • GroupWithMore - retains existing middleware + adds more
  • GroupWithNone - groups with no middleware
• renamed examples dir to _examples

Release 3.7.1

What was fixed?

Corrected static file serving example in README thanks to pull request from @cookiebody

Release 3.7.0

What's new?

• updated gzip middleware, now handles no content written to the response eg. browser won't download an error file when no content was written.
• updated logging and recovery middleware to use new ansi library for colors, reducing duplicate code in multiple projects.

Release 3.6.0

What's new?

updated NativeHandlerChain to avoid a shallow copy when chaining native handler pattern and lars

Release 3.5.0

What's new?

Added 308 = http.StatusPermanentRedirect for redirect that was't in previous versions of Go

Release 3.4.1

What was fixed?

Added another context workaround for chained handlers, this is not an issue with lars but rather the assumption that context.Context() is used with chained handlers only ( an incorrect assumption at that )

Release 3.4.0

What's New?

• added QueryParams() url.Values function to default context for caching multiple access to http.Request.URL.Query() Values; the normal behaviour is to re-parse every time.

Release 3.3.1

What was fixed?

Nothing in lars was fixed, just a workaround provided to save everyone that is using an external library that stored the http.Request as a map key.

eg. nosurf, gorilla context ..........

boy once people start using the built in context object on the http.Request they are going to find some fun quirks, because of the way context is tied to the http.Request libraries like nosurf that store the http.Request in a map key, but as soon you store a value the http.Request changes and then the http.Request cannot be found in the map anymore in another middleware after that.

I can just imagine the number of applications that could break because of this.... anyway the temporary workaround will save you, but if you're using
a non lars.Context handler be sure to shallow copy the request to avoid this issue.

// because 'r' is a copy of a pointer to allow the information to get
// back to the caller, need to set the value of 'r' as below with '*r'
func(w http.ResponseWriter, r *http.Request) {
    *r = *r.WithContext(context.WithValue(r.Context(), 0, "testval1"))
}

Release 3.3.0

What's New?

• updated to use std lib context and new embedded http.Context new in Go 1.7 ( set it up a long time ago for this, just finally found time to implement )

Don't worry, no breaking changes, Go 1.6 and earlier will still work as it always has.

Special Note

I don't know if it was an oversight or just an assumption about how middleware would be used with Go 1.7's new context integration into the *http.Request but there are a few quirks. As you know lars handles multiple handler types, including the native handler, this functionality is possible because of the way lar handles the middleware; lars does not chain the middleware in the normal way, but rather calles each in sequence; because of this all you have to do is call c.Next() or it has already been wrapped to do so for you transparently. OK getting back to the point, if you are not using lars.Context to set the context information you will have to set the request object so that the information gets back to the calling package. eg.

// because 'r' is a copy of a pointer to allow the information to get
// back to the caller, need to set the value of 'r' as below with '*r'
func(w http.ResponseWriter, r *http.Request) {
    *r = *r.WithContext(context.WithValue(r.Context(), 0, "testval1"))
}

this is not an issue specific to lars, but a quirk of the way context is tied to the http.Request object.