Start plain response as soon as certain

[victorges]

Using this library in one of my projects, I came to realise our API for Server-Sent Events stopped working when the request included an Accept-Encoding: gzip header.

Investigating on the gziphandler code I found out that, even though I added only application/json as the list of supported content types to be GZIPped, 2 little issues led to SSE stop working:

• The handleContentType function wasn't being checked until the response actually reached the specified minSize (which I left to the default). The Content-Type was already being set to an unsupported content type (text/event-stream) so we didn't need to wait all the first 1400 bytes before starting the plain response. Fixed this on the first commit.
• The Flush func was not flushing the underlying ResponseWriter when we were not gzipping the response. This is needed as we make sure Flush is called after every event we write to the response. Fixed this on the second commit.

One thing that is still slightly bothering me is that we are parsing the response headers every time the Write function is called. I'm thinking of adding a little "state-enum" in the gzip.Writer struct, indicating whether:

• We haven't even processed the original response headers yet
• We are accumulating data in the buffer to determine whether a plain or gzipped response will be done
• We are serving a plain or GZIPped response

I think this will make the logic much clearer as well. Please also let me know what you think of that idea and I could try to send it as a separate pull-request!

[victorges]

Great! I think I don't have access to merging this though, could you do it for me?

I'll try to do the state thing some time in the next few days :)

[jprobinson]

Thanks, @victorges & @fsouza!