Wrong setup.exe on http://www.cygwin.com/

Wrong setup.exe on http://www.cygwin.com/

Dear all,

I was just trying to upgrade my local package repository, but setup complains
that a newer version 2.678 is available. However, when I download it directly
using wget http://www.cygwin.com/setup.exe and execute it, I still get 2.677.

R: Wrong setup.exe on http://www.cygwin.com/

--- Ven 29/1/10, Jurgen Defurne ha scritto:

> Dear all,
>
> I was just trying to upgrade my local package repository,
> but setup complains
> that a newer version 2.678 is available. However, when I
> download it directly
> using wget http://www.cygwin.com/setup.exe and
> execute it, I still get 2.677.
>
> Regards,
>
> Jurgen

a proxy between you and cygwin.com is caching the old setup.exe.
Try refresh

Re: Wrong setup.exe on http://www.cygwin.com/

> On 03/02/2010 08:16, Morten Kjærulff wrote:
>> Hi,
>>
>> I tried downloading http://www.cygwin.com//setup.exe (note 2 //), and
>> got 2.680. http://www.cygwin.com/setup.exe is still 2.674 for me.
>
> You found a clever way to trick the caching proxy that's messing things up
> for you!
>
> Another thing that often works is to use a public open-proxy server to
> redirect the request for you; it only takes seconds to google a few up.

Another simple trick that usually works is to append
?some-random-stuff to the url, like:

Re: Wrong setup.exe on http://www.cygwin.com/

Nice. But of course, you would only try this if you suspect you're
getting a stale 'setup.exe' from a web cache. On the server side (at
cygwin.com), Apache's 'mod_expires' module could be used to send a
strong hint to HTTP caches to NOT cache 'setup.exe' in the first place.

After ensuring that 'mod_expires' is loaded, the addition to
'httpd.conf' could be as simple as:

No. It couldn't. The first time setup-1.7.1-1 was updated you'd see
this same critical problem. The situation here is that I have been
updating setup.exe to fix bugs and people are amazed and confounded by
the behavior of their proxy caches which don't retrieve the new version.
Changing the name doesn't help that in any way.

Re: Wrong setup.exe on http://www.cygwin.com/

On Tue, Feb 09, 2010 at 11:21:56AM +0000, G.W. Haywood wrote:

>Hello yet again,
>
>On Mon, 8 Feb 2010 Christopher Faylor wrote:
>> On Mon, Feb 08, 2010 at 09:21:30AM +0000, G.W. Haywood wrote:
>> >On Mon, 8 Feb 2010 Dave Korn wrote:
>> >
>> >> These both work:
>> >>
>> >> http://www.cygwin.com/setup.exe?&go_away_proxy!>> >> http://www.cygwin.com/setup.exe?go_away_proxy!>> >
>> >This could work too:
>> >
>> >http://www.cygwin.com/setup-1.7.1-1.exe>>
>> No. It couldn't. The first time setup-1.7.1-1 was updated you'd see
>> this same critical problem. The situation here is that I have been
>> updating setup.exe to fix bugs and people are amazed and confounded by
>> the behavior of their proxy caches which don't retrieve the new version.
>
>I know what the situation is, and I've been suggesting a way of
>improving it.
>
>> Changing the name doesn't help that in any way.
>
>[Sigh.]
>
>Yes it does, if you change it every time you update it.

Your suggestion was unclear.

So you're saying that we should change the setup available on the
website to 1.7.1-1, 1.7.1-2, etc. and possibly when a new Cygwin is
released: 1.7.2-1. Sounds like a lot of extra work to fix a "problem"
affecting a handful of people; especially when the majority of users
apparently have no problem just downloading the latest version. It
sounds like this major change in behavior would trade a minor amount of
proxy cache confusion for a major amount "What happened to setup.exe?"
confusion.

Perhaps more importantly, with the possible exception of updating the
web site to allow hints that setup.exe shouldn't be cached, I don't
believe that there is a problem here which requires a change. So there
is not going to be a change in the name of setup.exe.

I've implemented that suggestion. Now, in theory, all of the proxies
out there will not cache setup.exe. That should reduce cygwin mailing
list traffic at the expense of network traffic on cygwin.com and on the
networks that the proxies serve. I guess that's a good enough compromise
although I suspect that we'll still hear from misconfigured proxies.

Re: Wrong setup.exe on http://www.cygwin.com/

On Tue, Feb 09, 2010 at 01:03:23PM -0500, Christopher Faylor wrote:

>On Tue, Feb 09, 2010 at 10:27:31AM -0700, Warren Young wrote:
>>On 2/9/2010 9:49 AM, Christopher Faylor wrote:
>>>with the possible exception of updating the web site to allow hints
>>>that setup.exe shouldn't be cached
>>
>>In the PTC spirit:
>>
>> <IfModule mod_expires.c>
>> ExpiresActive On
>>
>> <FilesMatch "\.exe$">
>> ExpiresDefault "now"
>> </FilesMatch>
>> </IfModule>
>
>Thanks Warren. I appreciate the PTC. This was already suggested here:
>
>http://cygwin.com/ml/cygwin/2010-02/msg00149.html>
>I've implemented that suggestion. Now, in theory, all of the proxies
>out there will not cache setup.exe. That should reduce cygwin mailing
>list traffic at the expense of network traffic on cygwin.com and on the
>networks that the proxies serve. I guess that's a good enough compromise
>although I suspect that we'll still hear from misconfigured proxies.
>
>Thanks to Steven for the original suggestion.

Btw, I did check the difference in http headers in the before/after
scenario and now see a new "Expires" field but I have no way of actually
checking this to see if it really does solve a problem.

Re: Wrong setup.exe on http://www.cygwin.com/

I doubt it'll make a significant difference. Browser caches turn over
pretty regularly, so between any two visits, the chance that there is
still a copy of setup.exe and it's still current is pretty low.

Browser caches matter more for resources needed on every visit,
especially those shared between multiple pages on that site.
(cygwin.jpg, for instance.)

I'd bet the ratio of setup.exe downloads to site hits is below 0.5.
Maybe even below 0.1.

You might check that web spiders don't download setup.exe. If they do,
I'd block them from it with robots.txt.

> Btw, I did check the difference in http headers in the before/after
> scenario and now see a new "Expires" field but I have no way of actually
> checking this to see if it really does solve a problem.

The Net panel in the Firebug extension for Firefox can do this. And
indeed, it looks like you haven't fully defeated caching yet.

On a cleaned cache, I get an HTTP 200 response code for setup.exe, but
304 (Not Modified) thereafter. If the cache were defeated, it would be
200 every time. Assuming you have fully restarted Apache, the next
thing to try is:

FileETag none

Incidentally, while poking around with this, I ran into a spate of
validation errors on the home page. One particularly ugly one is a
second <body> tag on line 261 of the home page.

The best way I know of to clean up things like this is with the Html
Validator Firefox extension:

After you install it, the View Source window is augmented to do
validation, with an error list coupled to the source listing, much like
the way code IDEs tie compiler errors to source lines. Because it's
right there in your browser and runs client-side, you get real-time
feedback about the cleanliness of your code as you work on the page.
Unlike other free validation services, you don't have to publish the
page for all to see before you can validate.

Re: Wrong setup.exe on http://www.cygwin.com/

On Tue, Feb 09, 2010 at 11:59:32AM -0700, Warren Young wrote:
>On 2/9/2010 11:05 AM, Christopher Faylor wrote:
>> Btw, I did check the difference in http headers in the before/after
>> scenario and now see a new "Expires" field but I have no way of actually
>> checking this to see if it really does solve a problem.
>
>The Net panel in the Firebug extension for Firefox can do this. And
>indeed, it looks like you haven't fully defeated caching yet.

I used both lynx and firefox's "Live HTTP Headers" plugin. Both reported
something like this:

Cache-Control: max-age=0
Expires: Tue, 09 Feb 2010 19:48:16 GMT

I think that's good enough. Putting more work into this is not something
that I'm signing up for.

>Incidentally, while poking around with this, I ran into a spate of
>validation errors on the home page. One particularly ugly one is a
>second <body> tag on line 261 of the home page.

Yes, others have mentioned this before. Please don't take my
appreciation for solutions to this particular problem as an indication
that I also want to hear about website cleanups. I really don't.

I debated whether I should make the above point because it sounds WJM
but decided that I'd better say something or this thread would morph
into people talking about their favorite web site validation tools.