[WEB4LIB] Re: Is Netscape dead? I asked Jeeves

[Vicki Falkland]

>> This is NOT an Ovid problem. It is a default setting in Explorer.
>
>Strange that it isn't a problem at OhioLINK then.  It *is* possible to
>handle this for IE at the server end, and the reasons for not doing so
>include ignorance, indifference, and insistence on single-browser
>development.
>
--<remainder of previous message below>--

At the server end? Ohhhh ok.
Well, unfortunately for me, I am not in a position to have anything at all
to do with our network server. Nor are we priviledged enough to have a web
"techie" on staff.
Different solutions for different situations me thinks. 
Our solution is as stated previously. Use Netscape in the library, and
offer advice to other network users who have trouble with it via the phone
and instruct them on how to change the default setting in IE. Changing
default settings in MS software is, after all, a way of life for many users.
In my ignorance, this solution suits my situation.

Thanks

Vicki




>To reiterate, Ovidweb generates a "download" by sending out text prefaced
>by the HTTP header:
>
>Content-type: application/octet-stream
>
>This is a little white lie.  The application/octet-stream type is defined
>in RFC2046 as "uninterpreted binary data, in which case the simplest
>*recommended* action is to offer to write the information into a file" [my
>emphasis].  In fact, the data is either text/plain or text/html and in a
>perfect world would be honestly transmitted as such, but I think we're
>agreed that the realities of life at a public workstation would make it
>problematic to manage and train the "Save As..." function for text
>displayed in the browser.  Hence the octet-stream hack.
>
>As I mentioned before, IE sometimes believes it knows better than you, and
>knows better than the server.  Regardless of the incoming content type, it
>will examine the incoming data, and if it decides it can display it, it
>will do so.  In this case, that's not entirely wrong, as the content type
>says the server has not interpreted it, and it may in fact be displayable.
>
>The preferred solution is to explicitly identify the incoming data as a
>file attachment, as detailed in RFC2183.  This also allows the server to
>provide a default file name.  So OhioLINK's database interface sends out:
>
>Content-type: application/octet-stream
>Content-Disposition: attachment; filename=download.txt
>
>On receipt of this, IE obediently pops up its Save As dialog with
>"download.txt" filled in as the default file name, as opposed to
>Netscape's default of "ovidweb.cgi".
>
>All of which is a long way around to saying: Ovid is one line of Perl away
>from making this work for IE; making it work better than in Netscape; and
>making it work in any other browser that conforms to these standards.
>
>
>Thomas Dowling
>OhioLINK - Ohio Library and Information Network
>tdowling at ohiolink.edu
>
>(Late breaking news: somewhere between Communicator 4.5 and 4.7, Netscape
>added support for the Content-Disposition header above, so it will also
>now default to "download.txt" if the server sends the header.)
>
>
>


____________________________________________
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
J.W. Grieve Library
Royal Children's Hospital
Flemington Rd
Parkville, VIC, 3052
Australia
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
ph: 61 3 9345 5108
fax: 61 3 9347 8421
email: library at cryptic.rch.unimelb.edu.au
URL: http://www.rch.unimelb.edu.au/library
____________________________________________
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=