|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: ARIN Policy on IP-based Web Hosting
Also sprach Andrew Brown >>Where on earth did you get the idea that mime typing requires all >>that? >not that it requires it, but that it usually happens. if i get a file >via http with a mime type that the browser "knows what to do with", i >usually don't get a choice. likewise if i get a file via email with a >octet-stream mime type, most readers won't show it to me by default. Usually, but not always, and it is a client config issue. wget, for example, dumps to a file regardless of the mime type I believe (I'm not intimately familiar with wget, but is the behavior I've seen from what little I've used it) >the mime type is made up, usually based on the file's extension, which >is, of course, passed along with the contents of the file when you >transfer it. it's no extra information in this context. Again, usually, but not always. And seeing as how many systems *cough*Microsoft*cough* behave so poorly when the mime type and file extension disagree, it seems we have some more real work to be done in this area...I won't argue that things are perfect, but the possibilities are there and you seem to be trying to shoot them down because things usually aren't done that way currently. So much for innovation using that logic. :) >when you initiate an "ascii" mode transfer, the remote ftpd translates >the file from local line termination to network oriented line >termination (ie, cr, or crlf or lf becomes crlf). your ftp client then >translates back to local line termination from network line >termination. this is how you can transfer files between windows >machines, macs, and unix boxes, and always end up with something you >can read locally. And this could *easily* be implimented in a web server and web client. Might I suggest a new mime type (are we eventually going to have to worry about mime type namespace issues?) indicating that this process is going on so that the client side can be told that this is what's going on? Perhaps text/plain-network, or something like that. >http doesn't do this. Currently...it could easily do so. I don't think that its necessary for the protocol to define this, when it could easily be handled by *gasp* indicating this process in the mime type, or perhaps even the transfer-encoding...just thought about that...haven't given it much though yet. :) -- Jeff McAdams Email: [email protected] Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
|