Transparent gzip-encoding for net/http: working code but critique welcome

[Johann Höchtl]

Correct me if I am wrong, but http has not yet got the functionality to transparently gzip-encode?

Anyway, might somebody tell me If I could improve the following working code:

https://gist.github.com/1950633

Line 38: The variable gz1 feels unneccessary only to fullfill the WriteCloser interface for defer. (without the defer the buffer doesn't get flushed and HttpResponse doesn't implement close) Maybe I can typecast? Other problems / improvements / more idiomism?

And line 50:

w.Header().Set("Content-Type", http.DetectContentType(buf.Bytes()))
fells very expensive to convert the possibly large buffer to bytes.

Somewhat unrelated: What would be the Content-Length?

Would be very nice to help me out and critique.

Greetings, Johann

[Andrew Gerrand]

It's easier to just wrap an http.HandlerFunc, rather than worrying
about readers and writers and whatnot.

I wrote a short blog post about it a while back. It's pre-go1 code but
it should be easy to fix up:
http://nf.id.au/roll-your-own-gzip-encoded-http-handler

Andrew

[Jim Teeuwen]

Somewhat unrelated: What would be the Content-Length?

 

 

The http package has resorted to omitting the Content-Length header entirely in certain cases.

It caused a bug where compressed output we sent to the client with the original file size in the header. Making the browser believe it was receiving data in chunks and initiating the range dance accordingly. Which in turn lead to the browser considering the response data corrupt -- The server was never sending it any more data because there was none to send.

If you are insisting on sending a Content-Length header anyway, it should probably be set to the size of the compressed data.

[Johann Höchtl]

I revived your snippet as gist
https://gist.github.com/1956518

The downside I see is that the handler is responsible to set the
content-type.

> Andrew

[frederickm]

The downside I see is that the handler is responsible to set the 
content-type. 

I didn't try to run it, but maybe something like this http://pastebin.com/48FNw6fC

[frederickm]

Here is a working version: http://pastebin.com/DZJuxyBC

[Johann Höchtl]

That's what I was missing: How to access the Buffer in ServeHTTP - by changing to bytes.Buffer it's now possible.

My version is simmilar, but can be assigned to specific handlers:

https://github.com/the42/schoolcalc/blob/master/webzapfen/webzapfen.go   127 - 139

Maybe I will extend it to an "adaptive" version which doesn't gzip compress, once multimedia files, already compressed files or images are served.

- Johann

[Naitik Shah]

For anyone else that arrives here looking for a go1 compatible gzip enabling http.Handler based on Andrew's suggestion might find this useful: https://github.com/daaku/go.httpgzip