The goal is to check whether a http.ResponseWriter is a wrapper around another http.ResponseWriter. If so, we can check what the wrappee implements besides ServeHTTP(...). Maybe it is itself a wrapper. Maybe it is a Hijacker or ReadCloser...
If this wrappee is itself a wrapper, the logic is recursive. This way, the top wrapper, which is a http.ResponseWriter, does not need to bear assumptions about what any of the wrappee may have implemented. It just asserts for what it is interested in. https://play.golang.org/p/cBeJHExtOh Now, I don't know if it solves your issue but that's a quick thought. On Friday, November 11, 2016 at 11:42:38 AM UTC+1, Felix Geisendörfer wrote: > > I haven't thought too much about it but there is possibly an alternative > logic by having the wrappers add a Wrap() http.ResponseWriter that would > return the wrappee. > > So first, one would test for that Wrapper interface, then return the > wrappee if the test turns out to be positive. Then one could assert for > various interfaces on this wrappee. > > Something to think about. > > > Maybe I’m misunderstanding your idea, but wouldn’t this require having to > go over every handler used by the application in order to see where this is > needed? > > If yes, then I don’t like it, because that’s exactly what I was trying to > avoid. The whole idea was to make the wrapping/instrumentation transparent > to all handlers. > > Cheers > Felix > > On 11 Nov 2016, at 11:35, atd...@gmail.com <atd...@gmail.com <javascript:>> > wrote: > > I haven't thought too much about it but there is possibly an alternative > logic by having the wrappers add a Wrap() http.ResponseWriter that would > return the wrappee. > > So first, one would test for that Wrapper interface, then return the > wrappee if the test turns out to be positive. Then one could assert for > various interfaces on this wrappee. > > Something to think about. > > On Thursday, November 10, 2016 at 12:09:32 PM UTC+1, Felix Geisendoerfer > wrote: >> >> Hi all, >> >> while working on instrumenting my application, I ran into the fact that >> capturing metrics such as status codes from my own http.Handlers is >> surprisingly difficult to get right. >> >> Therefor I created a package that hopefully avoids most of the common >> pitfalls. >> >> https://github.com/felixge/httpsnoop >> >> I would love for net/http experts to take a look at the "Why this package >> exists" section of the README, as well as the horrible hack required to >> make things work: >> >> https://github.com/felixge/httpsnoop/blob/master/wrap.go#L44-L163 >> >> Please let me know if you have suggestions for simpler approaches and/or >> spot any bugs in my implementation. >> >> Thanks a lot! >> Felix Geisendörfer >> > > -- > 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/-I5IZgJosYE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > > -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
