SlyMarbo / spdy

[deprecated] A full-featured SPDY library for the Go language.
BSD 2-Clause "Simplified" License
116 stars 13 forks source link

[Enhancement] http.Flusher #66

Closed EtienneBruines closed 10 years ago

EtienneBruines commented 10 years ago

(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:

func handle(w http.ResponseWriter, r *http.Request) {
    if f, ok := w.(http.Flusher); ok {
        f.Flush()
        // Flushed to client - http package
    } else {
        // Flush not supported - spdy package
    } 
}
SlyMarbo commented 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?

EtienneBruines commented 10 years ago

@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.

SlyMarbo commented 10 years ago

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).