Re: FTP type proposed solution..

From: Don Lewis <[email protected]>
Date: Wed, 26 Feb 1997 03:29:31 -0800

Arghh! I don't know what happened to my original reply.

On Feb 25, 11:08pm, Henrik Nordstrom wrote:
} Subject: Re: FTP type proposed solution..
} One more quote from the RFC: (I don't think this is implemented in Squid
} yet...)
}
} ---------------------------------
} 3.2.2. FTP url-path
}
} The url-path of a FTP URL has the following syntax:
}
} <cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode>
}
} Where <cwd1> through <cwdN> and <name> are (possibly encoded) strings
} and <typecode> is one of the characters "a", "i", or "d". The part
} ";type=<typecode>" may be omitted. The <cwdx> and <name> parts may be
} empty. The whole url-path may be omitted, including the "/"
} delimiting it from the prefix containing user, password, host, and
} port.
} ---------------------------------
}
} The typecode is the type of transfer done in FTP.
} a = ASCII
} i = IMAGE (binary)
} d = DIRECTORY

Thanks for digging up this quote.

IMHO, if we can't figure out the type of the file based on it's
extension (if any), then we should present two links for the file in a
directory listing, one with ";type=a", and one with ";type=i". If the
user selects the ";type=a" link, then we should transfer the file in
ASCII mode, and return the MIME type text/plain. If the user selects
the ";type=i" link, then we should transfer the file in binary mode and
return the MIME type application/octet-stream.

There are still a couple of cases that we need to take care of. The
first is what happens if we are presented with an ftp URL that doesn't
contain the transfer type tag and we can't figure out the file type.
IMHO, we should do the same as we do now. The other is what happens if
we are presented with an ftp URL that contains both the transfer type
tag and a filename extension that is listed in our known MIME types.
In this case I think the appropriate thing to do is use the specified
transfer type, ignore the extension, return the MIME types text/plain
or application/octet-stream as appropriate for the transfer type, and
hope that the user knows what he is doing.

Also, as I mentioned that last time this subject came up, there are two
places in the squid code that parse the filename to look for extensions
that can be compared to the known MIME types. One determines what the
transfer type should be and the other determines what MIME type should
be returned in the response. The bug (other than just being duplicate
code) is that these two pieces of code parse the filename differently.

The current implementation does ASCII mode ftp transfers if and only if
the mime_encoding is "7bit". I think some of the 8 bit types (latex,
shar, and tex) should also be transferred in ASCII mode to get the
expected line termination. I don't know of any reason that a text file
using the ISO 8859-1 character set couldn't be safely transferred in
ASCII mode even though it contains characters with the upper bit set.
On the other hand, I've seen Postscript files that could not be safely
transferred in ASCII mode.

                        --- Truck
Received on Wed Feb 26 1997 - 03:40:46 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:34:33 MST