Closed EtienneBruines closed 10 years ago
Spdy doesn't implement the http.Flusher
interface, since data is never buffered when spdy is being used; it's sent automatically. I could add a Flush
method that does nothing, but it seems unnecessary. Would it be useful?
@SlyMarbo Thank you for such a quick response. A few thoughts on the matter:
(1) the Flush
method could panic to prevent design flaws;
(2) the Flush
method could indeed be added, to make transitioning from HTTP to SPDY easier; this reason however does not stand, because a type assertion is used (and therefore the code will always compile and run).
(3) you could leave out the Flush
method as suggested.
(4) confirmed it falls-back correctly on the http
-package when no SPDY Connection can be set up, where it can use Flush
I will leave it up to you whichever you think is best. You have greatly helped me with this :-). Thank you.
I think I'll leave it as it is, since flushing is unnecessary. If you need to check whether it's using spdy, you can always use spdy.UsingSPDY(w)
.
If a connection doesn't support spdy, my code isn't run; it'll use the normal behaviour in "net/http"
(and will thus support Flush
).
(I'm just putting it here at the Issues-tab, because I'm not 100% sure it's even possible with the SPDY-implementation. )
The following code works with the http.ListenAndServeTLS, but not with spdy.ListenAndServeTLS: