On Sun, Jul 09, 2000 at 05:07:40PM -0400, Tim Peters wrote:
And a new problem popped up early this weekend (maybe Friday already): when I click the "Browse CVS Repository" link near the bottom right of
http://sourceforge.net/cvs/?group_id=5470
IE5 pops up a box asking me whether I really want to download file "cvsweb". Useless! This used to work fine, and I sure haven't changed my IE setup. Clearing the browser caches didn't help. The link resolves to
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi?cvsroot=python
today, and I don't know whether it resolved to something different last week. Also have no idea how browsers decide what to do -- it's not simple & straightforward, like e.g. floating-point arithmetic <wink>. .cgi is not an extension registered on my machine either.
Actually, it's supposed to be simple and straightforward. Unfortunately, certain Windows programs decided not to play along ;) HTTP responses contain a header 'Content-Type', which should be a mimetype for the file the HTTP response accompanies. They may also contain a 'Content-Disposition' header, which contains a suggested filename for when writing the file to disk. Now, the Content-Type thing is working okay nowadays, even though you can override it (sometimes) using the 'helpers' or 'applications' settings in your browser ;) But the Content-Disposition header creates a ton of confusion on IE. Some versions of IE seem to think that when it's present, a file should *always* be saved to disk, instead of shown, regardless of mimetype and/or helper applications. Also, some versions of IE go completely bananas if the Content-Disposition header is listed before the Content-Type header, and gives a very strange response: a 'page not found' error without saying which page it was trying to download ;) I know all this for a fact, because we provide our customers with 'Secure Webmail', a web interface to their email (next to normal interfaces, of course.) And for a long while our helpdesk was forced to tell our IE-using users to switch to Netscape, because IE was giving the above errors, and more. Eventually, my boss and I spent two days with a couple of windows boxes trying to figure out why this was happening. by tcpdumping and tracing exactly what was being sent and received. (Not that easy, given that it was 1) a switched network on our side, 2) a special load-balancing-switch on the server side, and 3) 'Secure' Webmail, using SSL ;) We managed to track the above bugs when using non-SSL connections, but a few bugs remained in SSL only, and we never figured out how or why :P The bugs are really obscure: IE sometimes giving an error when clicking on 'new mailbox', but usually it went fine. IE giving a popup with some unclear error message out of the blue. Sometimes showing images, sometimes offering them for download. All in all, I'm no longer suprised when something dynamic (CGI scripts, php/asp/jsp pages, whatever) refuses to work properly with IE ;) Quite a depressing thing to know, this, but you can't always blame the website-owners or the software developers. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!