Re: Packet size

From: J Wunsch <j(at)uriah.heep.sax.de>
Date: Thu, 23 Nov 2000 22:57:36 +0100

As Lam Nguyen wrote:

> I found that in the address below
> ftp://ftp.de.freebsd.org/pub/FreeBSD/releases/i386/4.1.1-RELEASE/bin/
>
> two packets 'bin.ai' and 'bin.cc' have different size respect to the others (240640 bytes). Is there anything wrong?

Yes, but not with the server. :) The problem is most likely the
proxy server you are using, we've seen this kind of symptom before
and tracked it down to being problem of at least some HTTP proxies.

If you were using plain FTP, things would be easy; FTP has no inherent
file type information, so the user is responsible for telling the
server about potential file conversions. You do so by saying `type
binary' at the beginning of your session.

If you were using plain HTTP, things would be easy, too; HTTP carries
over file type information in the headers of a transfer. Now it's the
responsibility of the server administrator to ensure that e. g. all
files are being transferred as `application/octet-stream' in order to
tell anybody to not modify them during transport.

However, if you're using an HTTP -> FTP gateway, such as Squid when
requesting an FTP URL, things are getting difficult. The proxy has to
add type information to the (untyped) FTP data. At least some proxies
(like Squid) do this by guessing the file type from the `filename
extension'... Now consider files with an extension like `.cc' --
Squid is interpreting them as C++ program source code, basically a
form of a text file, and it converts linefeeds into carriage-return/
linefeed sequences if you are running a client on a platform that uses
this convention for text files. Similarly for .ai, although it
currently escapes me what that might stand for... Ah, Apache's
`mime.types' file tells me:

application/postscript ai eps ps

So in short, you might be lucky by using another proxy (i think we've
once proven that Netscape proxy doesn't do it that way), but the only
guarantee is to use plain FTP without an HTTP gatewaying proxy.

The best fix would be to avoid those filenames altogether when
creating a FreeBSD distribution. However, that's very easy to demand
but difficult to get. FreeBSD distributions have to consider not only
one but all possible ways of distributing the files. Since some of
the possible distribution media (like DOS floppies or hard disks, but
also plain ISO-9660 CD-ROMs without extensions for presenting long
filenames) have a very limited possible namespace, it is difficult to
find a set of filenames that is all together, descriptive, valid for
all distribution media, and allows for a sufficient number of small
files to allow transferring them over small media like floppies.

I'm just adding Jordan here as a reminder of this potential pitfall,
and to `ping' him for finding a possible solution to the problem...

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL
http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-hubs" in the body of the message
Received on Thu 23 Nov 2000 - 23:24:29 CET

search this site