On Mon, Dec 01, 2008 at 08:20:07AM +0100, lee wrote:
> On Sun, Nov 30, 2008 at 05:46:26PM -0500, Thomas Dickey wrote:
> > On Fri, Nov 28, 2008 at 03:30:09AM +0100, lee wrote:
> > > The web page looks good --- but it seems to tell me that it isn't
> > > possible to have a setting to reject all cookies in the
> > > ~/.lynxrc. Lynx itself won't save that setting, either, and I'm tired
> > > of changing the setting every time myself.
> >
> > Which setting is that? (If it's in the "options" menu, that can be changed
> > using the ENABLE_LYNXRC feature).
>
> The one I change? That's in the options menu. There's a footnote or so
> in the options menu saying that some of the settings will not be
> saved, and the cookie setting is one of them.
The ENABLE_LYNXRC settings in lynx.cfg override those. Sounds like you're
talking about this section:
Security and Privacy
Cookies : [ask user__]
Invalid-Cookie Prompting (!) : [prompt normally___]
SSL Prompting : [prompt normally___]
If you have this in lynx.cfg
ENABLE_LYNXRC:force_cookie_prompt:ON
then the screen changes to this:
Security and Privacy
Cookies : [ask user__]
Invalid-Cookie Prompting : [prompt normally___]
SSL Prompting : [prompt normally___]
By the way, lynx will read whatever config-file you have in the $LYNX_CFG
environment variable. My $LYNX_CFG points to a file that begins
include:lynx.cfg
so I don't have to edit the system's copy...
> > > So how do you make lynx display gziped files?
> >
> > Actually you tell lynx to tell the server that it can display gzip'd files.
> > Then (if the server cooperates), it'll deliver gzip'd files, and lynx
> > will display them.
> >
> > .h2 PREFERRED_ENCODING
> > # When doing a GET, lynx tells what types of compressed data it can decompress
> > # (the "Accept-Encoding:" string). This is determined by compiled-in support
> > # for decompression or external decompression programs.
> > #
> > # Values for this option are keywords:
> > # NONE Do not request compressed data
> > # GZIP For gzip
> > # COMPRESS For compress
> > # BZIP2 For bzip2
> > # ALL All of the above.
> > #PREFERRED_ENCODING:all
> >
> > (not all servers cooperate - and of course lynx _could_ be built without
> > gzip support - but this is where it's configured at runtime in lynx).
>
> Hm, I put that into ~/.lyncrc, with PREFERRED_ENCODING:all enabled
> ("#" removed). Starting lynx in an xterm and following a link to a
> gziped file brings up and archive manager. Doing the same on a console
> makes lynx offer me to either download the file or to cancel.
You can see (at least) part of the problem using lynx's -trace option
(or toggling to trace with ^T). Lynx should be sending a header saying
what it's accepting, and the server will tell what it's sending.
Beyond that, it's up to the server to recognize the content type,
and for lynx to recognize what type of presentation to use.
> That is using apache2, running on the same host. I didn't change the
> apache configuration in regard to this.
>
> Why does the server need to cooperate? It can send the file in any
> case, and lynx could just offer to download or to display it, or to
> cancel.
lynx could - but it's based on the mime type that the server tells lynx.
For example...
I looked around, found some gzip'ed files on my homepage - which the
server only says application/x-gzip - for instance. That's the
content-type which shows up in the "Lynx.trace" file if you use the
"-trace" option, or toggle trace on with ^T (control/T).
The server says
HTMIME: Date: Tue, 02 Dec 2008 00:55:31 GMT
Server: Apache/2.0.52 (CentOS)
Last-Modified: Mon, 01 Dec 2008 00:43:57 GMT
ETag: "17fc2b2-189cf-8189ad40"
Accept-Ranges: bytes
Content-Length: 100815
Connection: close
Content-Type: application/x-gzip
The "Content-Type" is useful -
But lynx is (following the rules outlined in the various RFCs)
looking for a line giving the "Content-Encoding", e.g.,
Content-Encoding: gzip
That doesn't appear, so lynx offers to download it. For local and ftp
files, lynx doesn't have that to look for, so it just uses the filename
as a clue (and it "just works").
> Hmm, interesting, I tried to display the same file with konquerer,
> galeon and mozilla, and none of them displays it. But I'm pretty sure
> that at least mozilla was able to display it when I tried last time
> --- that can have to do with changing the data in my home directory.
I tried firebox on the same file - didn't view. So we may be talking
about different cases.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Attachment:
pgp5KJ9ccCLgp.pgp
Description: PGP signature