That seems like an awkward default header, especially if it's not going to deflate it (which causes more issues such as needing the content-length header adjusted and checksums...) It just seems like a bad idea:(
A ridiculous number of sites use that header to determine whether or not they should provide content. Note they don't actually provide encoded content, they just won't provide the non-encoded content if you don't send that header. (I assume this is the reason for it; I have no inside knowledge.)
IIRC http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd did in the past, though it no longer appears to. I know I've run into it in _many_ other places but it's been awhile and I no longer remember the various ones. I should also probably note that they were universally _not_ locations which you would generally be hitting programmatically.
I've been building a webcrawler that casts a pretty wide net and I've yet to run into it. I'm not just talking about API endpoints and stuff - I've never run into this doing general crawls of the web.
Maybe I'm alone on this, but I've never thought "I have to upgrade to a new Ruby point version anyways, why not just rewrite everything in Python/Perl/PHP(?) while I'm at it?"
The clickbait title is pretty obnoxious. I know that it is the current craze to style that way, but I can't help but imagine that a more helpful title would be something like: "Ruby 2 breaks existing projects by adding Accept-Encoding: gzip"...
How about "Test suites are awesome and help you find bugs during major upgrades"? I mean, this is basically your standard old "Regression tests helped us find a break in our software when performing a major upgrade!" story, rather than a "OMG, Ruby 2 will kick your dog and knock up your wife, avoid at all costs!!11" warning tale.
This appears to be documented[1] behavior for Ruby.
Here's a quote about the header string specifically:
"If initheader doesn't have the key 'accept-encoding', then a value of "gzip;q=1.0,deflate;q=0.6,identity;q=0.3" is used, so that gzip compression is used in preference to deflate compression, which is used in preference to no compression. Ruby doesn't have libraries to support the compress (Lempel-Ziv) compression, so that is not supported. The intent of this is to reduce bandwidth by default."
I'm not involved in Ruby / Rails development, but it's interesting to note that there was a pull request[2] on the Rails core about enabling gzip compression by default. It was ultimately decided best left up to the webserver and closed with the following quote:
"Rails should focus on being an MVC.
Enabling Gzip was an idea, but I think we now have enough arguments to not implement it ;)
IMO feature closed"
This looks like one of those good arguments. From what I can tell, this isn't a Rails problem, but a Ruby problem. I happen to agree that enabling gzip compression is good practice, but I don't think it should default to enabled at the application layer.
The pull request about Rails gzip compression talks about compressing http responses from Rails. While the blog post above, and the Ruby documentation of Net::HTTP, are talking about Ruby's new shiny default of compressing http requests (without care of the compressed response).
Other than including the words 'gzip compression' the two topics are very different.
18 comments
[ 6.0 ms ] story [ 52.1 ms ] thread1. default request header on by default 2. support for deflation off by default
WAT?
Less Rails - less fails. Simple!
good one.
This is textbook clickbait. Yawn.
Here's a quote about the header string specifically:
"If initheader doesn't have the key 'accept-encoding', then a value of "gzip;q=1.0,deflate;q=0.6,identity;q=0.3" is used, so that gzip compression is used in preference to deflate compression, which is used in preference to no compression. Ruby doesn't have libraries to support the compress (Lempel-Ziv) compression, so that is not supported. The intent of this is to reduce bandwidth by default."
I'm not involved in Ruby / Rails development, but it's interesting to note that there was a pull request[2] on the Rails core about enabling gzip compression by default. It was ultimately decided best left up to the webserver and closed with the following quote:
"Rails should focus on being an MVC.
Enabling Gzip was an idea, but I think we now have enough arguments to not implement it ;)
IMO feature closed"
This looks like one of those good arguments. From what I can tell, this isn't a Rails problem, but a Ruby problem. I happen to agree that enabling gzip compression is good practice, but I don't think it should default to enabled at the application layer.
[1] - http://ruby-doc.org/stdlib-2.1.0/libdoc/net/http/rdoc/Net/HT...
[2] - https://github.com/rails/rails/pull/7327
Other than including the words 'gzip compression' the two topics are very different.