CC @bradfitz

We've basically stopped adding these other methods precisely for the reason you identify.

Errors have the nice property that the API is very simple and wrappers really change very little.
That's not true of http.ResponseWriter.

Suppose you had an http.ResponseWriter wrapper that did gzipping of data passed to Write.
Suppose it implemented Unwrap so that it could be hijacked.
But it chose not to implement WriteString.
If you used As(w, &writeStringer) to look for a WriteString further down the chain, you'd end up bypassing the gzipping accidentally.

It's also unclear that adding As at this point would help much, since we can't rewrite all the code in the wild that doesn't use it, nor can we rewrite all the code in the wild that doesn't implement Unwrap, and now we'd have two ways to do it (only one of which is guaranteed to work - the old way).

We are aware of the problem, though, and if/when we get to designing a second version of the http server API we should definitely think hard about how to repeat this mistake.

But I don't see how this specific proposal improves the situation given the large amount of existing code.

I don't think that the .As approach would work with io.Reader/Writer though, for the reason you outlined. The optional interfaces there end up changing the semantics in ways that don't lend themselves to wrapping. I still think it might work for some of the ResponseWriter cases though.

I know Brad Fitz started looking at making a v2 of the http client. I hadn't heard anything about a v2 for http server.

I guess the question is what strategy makes more sense: a hard v2 with no backwards compatibility or a continuing evolution of what exists. I think this could be made entirely backwards compatible or at least mostly compatible with only some optional interfaces accidentally by passed.

For ResponseWriter, it might make more sense to have http.ResponseWriterIs(w, enum) bool so that there would be a way of adding a method but separately signaling whether you actually support it by checking your wrapped ResponseWriter. It could first see if w has Is(enum) bool and if so, try that, if not just check for the optional method as is done now. Code that doesn't implement the Is method will continue to work, but new code can explicitly delegate. The enum would be something like int8 that specifies the handful of optional interfaces that make sense to wrap, as opposed to Errors.As, where there is a potential infinity of optional interfaces.

I guess the question is what strategy makes more sense: a hard v2 with no backwards compatibility or a continuing evolution of what exists.

But as I noted in my comment above, adding ResponseWriterAs isn't backwards compatible. Code would still have to deal with all the special case methods that exist today - they're not going away and can't be shoehorned into a different API.

Maybe when it's time to add the next such method on ResponseWriter we should talk more about this proposal, but right now it doesn't seem like it simplifies anything.

It wasn't clear to me before why ResponseWriterAs wasn't backwards compatible, since the examples were around io.Writer, but I see now that the problem is that old middleware would be confused by new ones.

Basically, there are two ways to do ResponseWriterAs. One, you can have new middleware just implement all the interfaces and then use the As to delegate which ones are actually useable. This would confuse old middleware into thinking they could use them when sometimes they couldn't. Two you can implement nothing and use As to go up the Unwrap chain (as is done in errors.As), but then old middleware would think that the interfaces weren't useable even when they are.

I think two is not the worst failure case, but I concede that it's not really backwards compatible.

Closing the issue. In the event that someone proposes a new optional interface for ResponseWriter, I think something like ResponseWriterAs should be created for that new optional interface, but I don't think that's on the horizon at the moment.