|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: ARIN Policy on IP-based Web Hosting
(Last post on the subject; this has nothing to do with NANOG anymore. ;-) On Thu, 31 Aug 2000, Jason Slagle wrote: > Not all of us enjoy point and clicky interfaces (Even lynx in this context > is point and clicky). HTTP has nothing to do with "point and clicky". It's a transport protocol. You're thinking of a particular client implementation. > I don't see the ability to implement the functionality of command line FTP > (Yes, I know it COULD be done, but it is a hack at best. ls = transfer > directory listing. No, HTTP has the chance to do directory listings in a manner which *isn't* a hack; using /bin/ls for a directory listing is a client parsing mess. Using something like multipart MIME digests full of URLs would be a perfect answer to directory listings, and addition of metadata through various "implementation-defined" headers would be trivial, potentially giving you even more per-reference information than you can get now with FTP. > And what of ASCII and BINARY data types. ASCII transfers still have > use.) This sounds suspiciously like Content-Transfer-Encoding. > I don't consider this a benefit as I already have enough problems with > HTTP servers having the wrong mime type for .gz. I'm TRANSFERING a > file. The mime type is mostly irrelevant there. What do I need to know > if it's a image/jpeg if I'm just transfering it to my local drive. That's a client problem, one which isn't an issue with (for example) wget; all it does is grab the data at the URL you requested, and saves it to the filename it extrapolates from the URL, or to the filename you specify. Sorta like an FTP client. :-) > The MIME type is only beneficial if your attempting to do something with > the file after receipt. If I was I'd be using HTTP or another > protocol. I'm not, I'm transfering it. Then the addition of data type information is of no use to you. It's also of no hindrance. > > human-beneficial markup > > Once again, of no use. I don't want thumbnails if I ls -l a directory of > jpg's. "ls -l" *is* a form of human-readable markup. See above about handling of directory listings. > > caching if you have a nearby cache > > Theres no reason I can't cache it now. Squid manages to (Granted it's > taking ftp:// URL's, but you could hack up a "real" ftp proxy to cache. Wide-scale transparent FTP caching frightens me. Think of all the authentication information your cache would be collecting. Then think of all the possibilities for screw-up in the translation. We spent long enough getting transparent HTTP proxying semi-correct; I'd rather not go through that again. ;-) > When I want to choose from a list of files and "click" on the one I want I > already use lynx with ftp:// url's. But, often I don't want to do that as > I'm transfering multiple files. wget --mirror http://server/path/ -- Edward S. Marshall <[email protected]> http://www.nyx.net/~emarshal/ ------------------------------------------------------------------------------- [ Felix qui potuit rerum cognoscere causas. ]
|