From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 19 Oct 2009 10:05:39 +0100 From: Eris Discordia To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <1EE8D30F45EA3DBC0F877B25@[192.168.1.2]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [9fans] utf-8 text files from httpd Topicbox-Message-UUID: 8a545976-ead5-11e9-9d60-3106f5b1d025 The decision whether to open in place or save to disk based on MIME type is up to the browser. For example, I set my browsers to ask to save to disk application/pdf documents (rather than opening them with Adobe Acrobat's problem plugin). A MIME type of text/plain (without any specification of encoding) is correct (and expected by any mainstream browser) for text files. Opera opens those by default but can be set to do any one of a variety of tasks when encountering text/plain. All mainstream browsers also include encoding autodetection routines which may or may not fail depending on your file's contents. All mainstream browsers also allow you to select an encoding to decode and view your document in. Assuming the right bytes arrive at your client it is always possible to read the file in the right encoding. The encoding specified in response header has no say in the bytes that are transmitted. If your "any browser" includes Opera try Preferences > Advanced > Downloads > (Uncheck "Hide file types opened with Opera") > Quick Search text/plain > Edit > Action: Open with Opera (if the setting has been altered). Then retry visiting your remote file. Even if response header contains the wrong encoding (ISO-8859-1, EUC-KR, whatever) or no encoding specification at all Opera should retrieve the document and display it. If the display is wrong, try View > Encoding > Unicode > UTF-8. The behavior you describe of "having to download the file" and "characters being garbled" is not "any browser" sort of behavior. Neither Opera, nor Firefox, nor Chrome display such behavior for the example I have supplied below. If all else fails... why not wget -S [URI] and check (and probably post) the response header? This resource, for example: results in this response header: > HTTP/1.1 200 OK > Date: Sun, 18 Oct 2009 10:45:56 GMT > Server: Apache > X-Powered-By: PHP/5.2.8-pl2-gentoo > Cache-Control: no-store, no-cache > Connection: close > Content-Type: text/plain And there's no problem whatsoever with its display in either Opera, Chrome, or Firefox. Opera Info Panel says, by the way: > Encoding (used by Opera): > - not supplied - (windows-1252) --On Sunday, October 18, 2009 20:34 -0400 Akshat Kumar wrote: > I'm trying to put up a plain text file containing UTF-8 > characters from httpd, but when viewing it from any > browser, it comes off as an ASCII file that needs to > be downloaded (so, those characters are garbled). > Is this due to some behaviour of httpd? > > ak >