Can you provide some example code showing the problem?
I don’t understand why you are wrapping the ResponseWriter. If you need to
pass along metadata then wrapping makes sense, but why not just pass the
original interface and do the type switch in each handler?
type RetryResponseWriter struct {
http.ResponseWriter
Count uint
…
}
func handler1(w http.ResponseWriter, r *http.Request) {
rrw := w.(RetryResponseWriter)
switch v := rrw.ResponseWriter.(type) {
case http.Hijacker:
…
case http.Flusher:
…
case http.CloseNotifier:
…
}
…
Matt
On Tuesday, January 16, 2018 at 7:53:40 AM UTC-6, Marco Jantke wrote:
>
> Hi everyone,
>
> I am currently working on a retry middleware for an http proxy. It is
> wrapping the original response writer and only in case the forwarded
> request should not be retried, it passes calls to `Write()`,
> `WriteHeader()` etc directly through to the original response writer. Now I
> am struggling with the fact, that response writers have different
> capabilities dependent on their type. Namely they can be `Hijacker`,
> `Flusher` or `CloseNotifier`. The problem is that my wrapper should have
> the same capabilities as the wrapped one, but I don't see any other way
> than creating all different types and using the proper one after doing type
> assertions on the response writer I am wrapping. Those types would be for
> example: `ResponseWriterWrapper`, `ResponseWriterWrapperWithFlush`,
> `ResponseWriterWrapperWithHijack`,
> `ResponseWriterWrapperWithHijackAndFlush`....
>
>
> Does anyone have an idea how to approach this problem in a more reasonable
> fashion?
>
--
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.
