Re: Corrupted GIFs through proxy.

Phil Hochstetler (phil@sequent.com)
Fri, 14 Oct 1994 01:51:39 +0100

Date: Fri, 14 Oct 1994 01:51:39 +0100
Message-Id: <9410132347.AA23396@eng2.sequent.com>
From: Phil Hochstetler <phil@sequent.com>
To: Multiple recipients of list <www-proxy@www0.cern.ch>
Subject: Re: Corrupted GIFs through proxy.

I tried a "telnet mail.border.com 80" and did a "GET / HTTP
1.0<CR><CR>" and got back 2/3 of the home page. It looks like to
me that yes, it is a bug in the server but not the bug described in the
below mentioned file (which talks about the client sending too much
to the server). My guess here is that the server is interacting
poorly with the OS in the area of closing down a socket after the
last write. Many operating systems require setting some "SO_LINGER"
flag that tells it to not finish the close until the remote end
has read (and ACK'ed) all the data that has been written. Without
this flag, the OS may choose to discard data just written but not
delivered or read by the remote machine. Comments?

--
Phil Hochstetler		UUCP:        uunet!sequent!phil
Sequent Computer Systems	INTERNET:    phil@sequent.com
Beaverton, Oregon		COMPUSERVE:  70750,304

Previous mail from Henrik Frystyk states: |Subject: Re: Corrupted GIFs through proxy. | |The problem is well-known from other situations but I have not seen it |with gif-files. Its is due to the reaction of a 0.9 server when talking |to Mosaic (the TCP window gets filled up with no ACKs sent back). I have |explained the symptoms at the page | | http://info.cern.ch/hypertext/WWW/Daemon/Bugs.html | |which I use to explain known bugs or eqivalent information. Currently |there is little to do as the HTTP protocol can't change the status code |on the fly. | |The quick solution is - get a new server! | | |-- cheers -- | |Henrik Frystyk |frystyk@w3.org |+ 41 22 767 8265 |World-Wide Web Project, |CERN, CH-1211 Geneva 23, |Switzerland | |> When I connect via the proxy to certain web servers, gif files |> transmitted by the foreign server get corrupted when passing |> through the proxy. They display as mostly black. As I say, this |> only occurs with a small subset of web servers. Has anyone else |> run across this symptom? As an example of what I mean, check out |> the web server at http://mail.border.com/ - of course, only try this |> out if you are running through the cern proxy - it displays OK |> if you're not running through the proxy. I'm trying to figure |> out if the problem is with the proxy, or the server...