Lighttpd

672   etag_mutate(con->physical.etag, sce->etag);
673   response_header_overwrite(srv, con, CONST_STR_LEN("ETag"), CONST_BUF_LEN(con->physical.etag));

Why would you disable etags if you need mod_compress? And i don't like hacks :)

And why should static-file.etags influence mod_compress?

@stbuehler he wants to disable etags for the same reason the static-file.etags has been created (http://redmine.lighttpd.net/issues/show/1209).

To resume : In multiple server configuration Etags are not the same for all the webserver. (May be they are with le mod_compress etags generation algorithm, I do not know ...)

"And why should static-file.etags influence mod_compress?"

May be there should be a compress.etags disable options.

Tell me if i am wrong, I just want to have more explanation about why disabling etags in mod_compress looks so crazy ;)

stbuehler wrote:

Why would you disable etags if you need mod_compress? And i don't like hacks :)

And why should static-file.etags influence mod_compress?

@stbuehler why you think disable etags for mod_compress is a bad idea? could you explain more on it
Although let static-file.etags disable etags for mod_compres is not as nice as add a new config options to control it, but I don't think disabling etags in mod_compress sounds wired.

stbuehler wrote:

Why would you disable etags if you need mod_compress? And i don't like hacks :)

And why should static-file.etags influence mod_compress?

To the first; to save bandwidth; In a multiple server farm etags don't do much good, and they are kinda redundant if you use mtime/size only. So to save bandwidth, i disable them. See also http://developer.yahoo.com/performance/rules.html#etags

We also use mod_compress to lower our bandwidth even more, however i'm getting a bit sick of having to comment out the ETag line and recompile lighty with that single change for every upgrade i do.

So it should either be influenced by static-file.etags, or another setting, which would do exactly the same, but takes up more configuration file space. I for one cannot believe it if someone would want to disable static-file etags, but wouldn't mind if mod_compress overrules their 'no-etag' decision and adds ETags without bothering to look at any relevant config options.

Why did you close this bug and ask for feedback at the same time? That's basically spitting in the reporter's face. "I'm pretending to ask for more info, but I don't actually care so I'm closing the bug now."

This is definitely a bug. It makes no sense that you can disable it for static files, but not for compressed files. The ETag setting should be a global setting (etag.enable) which affects everywhere lighttpd adds the header.

I also think that this is definitely a bug as the logic is quite simple. The output of mod_compress is a static file, so why can it not accept static-file.etags="disable"?

I also don't really understand why its status is set to "invalid", because I think the propose fix seems to be good enough. Perhaps because the word "hacks" is being used instead of "fix" :)

To work around this problem, I applied the "real hacks" using mod_magnet with LUA script, and also forced my backend to gzip the files.

I have the same problem here. We need to deactivate eTags on http headers but using zip compression for static files. It would be great if this bug (thats - a - bug) get resolved.