New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Well, the person who wrote that page, their wget obviously supports SSL compression.
@LowEndAdmin, @Daniel: Well on a fresh Debian i have to call wget via
wget --header="Accept-Encoding: gzip,deflate"so it uses SSL-compression. A normal wget call does not accept SSL-compression.Well, the person who made that page is using OS X to DL it, and in recent versions OS X no longer comes with wget, and encourages people to use curl.
However it can be installed still from source, so maybe the one from source comes with it pre-enabled, and the Debian pre-compiled one does not.
That puts the whole incident into a completely different light. I mean he could also simply put up an alias of
wget="wget --header='Accept-Encoding: gzip,deflate'". We can't proof. (referring to being cynical)Maybe he should revise his text and declare how his custom wget is setup.
So to put it straight:
wgetin its original state does not use compression-over-SSL. You have to manually enable it via--header="Accept-Encoding: gzip,deflate". So everybody normally running wget will not "benefit" from the SSL-compression. The download will be the same as over normal HTTP.However, he is using OS X. OS X does not come with
wgetshipped but withcurl. He must therefore got hiswgetsomewhere else, maybe compiled it from sources. He, however, did not state if he compiled it with compression enabled by default. He does not write about his custom set-up at all. He takes his custom set-up to be valid for everybody.Additionally, we do not know, if he has set-up an alias to wget="wget --header='Accept-Encoding: gzip,deflate'".
And then he screamsn "xxx are cheats". Well, sapere aude my friend.
@kylix - you sure? Accept-Encoding deals with HTTP level deflate which is NOT what is talking about here.
I wonder who else is doing this? Makes me want to run down a list.
At least a lot uses a 0's file. So, maybe you are getting some gzip compression too.
He used the "https" link anyway. http://i.imgur.com/LcQ1t.png
The ssl is forced and was one of the points he raised. They hosted the test file on their support ticket site which requires the ssl.
Forces ssl or not, you have to manually say wget to use gzip or deflate. This guys detected "cheat" is so low...
Argh. No. You tell wget to use gzip or deflate on the HTTP 1.1 level. However the compression detected here is the TLSv1 deflate support which is one layer below HTTP (or something like that, for those who know the OSI model), and it comes in stock standard OpenSSL 0.9.8+.
Speaking of Singlehop, I submitted a spam/abuse report to them 4 days ago.
They just got back to me with a response.
Maybe I should blog about it.
You sure they didn't cheat when they wrote that response?
Considering the answer boiled down to "We think they were taken care of and the matter is resolved. Please check for us and let us know if it was taken care of."...
Santrex is doing the same thing.
Where?
That's an unnatural amount of compression - because guess what I see when I open the file? ^@^@^@^@^@^@^@^@ (aka nulls)
@Daniel:
Yes, they are. I downloaded 100 mb in 1 second on a 11 Mbit connection/
Try this one: http://vpsadmin-us.santrex.net/100mb.bin
Well we have been a previous customer of singlehop and the service and support was great, can't believe they would stoop this low... but once again it may not have been on purpose.