[Python-Dev] Sourceforge Interface Concerns

[Thomas Wouters]

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!