[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Other uses for <!-- X-URL --> and <BASE HREF>

From: pAb-032871
Subject: Re: lynx-dev Other uses for <!-- X-URL --> and <BASE HREF>
Date: Tue, 20 Jun 2000 04:50:43 -0700

Right, I'm kind of drifting off-topic again [as usual  ;-) ],
but some of this could be interesting.

In "Re: lynx-dev Other uses for <!-- X-URL --> and <BASE HREF>"
[19/Jun/2000 Mon 13:40:25]
Klaus Weide wrote:

> > The automatic insertions of;
> > <!-- X-URL: http ://www.server.dom/~username/ -->
> > <BASE HREF="http ://www.server.dom/~username/">
> > are very useful, keeping relative links in dowloaded/saved HTML
> > current [spaces added to avoid bad links in mail archive].
> Not everyone agrees that this is a good thing; in the latest
> Debian lynx package, the maintainer has disabled this behavior
> by default (see PREPREND_* in lynx.cfg), after a complaint that
> "Lynx download mangles html files".

Hmm, "mangle" seems a bit strong, but I guess that you're paraphrasing
the actual complaint.  Not that I've seen many pages which already
contain a <BASE HREF=> element, and fewer still where the URL
given is different from the actual location, but if some author
has to move a file and is feeling lazy they might add the *old*
BASE instead of trying to update every single link.

I should see if Lynx honours this alternate BASE when p)rinting
the source view.  It probably doesn't even *see* the tag when
downloading, because in that situation it doesn't do any parsing.

The only *problem* I've had with it is that later, loading the
local HTML in a graphical browser ["Gozilla" in this example],
it often tries to start up the modem without asking.  What it's
actually doing is seeking out the absolute locations of inline
images, but to me, on a time-metered ISP, this behavior is just
plain rude.

And the only thing wrong with the tags themselves is that Lynx
doesn't bother nesting them between the <HEAD> tags, if present.
This is pretty minor, and I can see why it's just added to the
beginning of the file instead, without getting too fancy.

> > How hard would it be to add this to text/plain files as well?
> Probably not hard.
> But quite different in effect - in text/html, this information is
> hidden away, in text/plain there's no way to hide it.

Yes, that was kind of the idea: to plainly mark where a text rendering
of some remote HTML came from.

> I also think it is dangerous, for downloaded files that are actually
> some binary type but mislabeled as text/plain.  The binary file would
> be corrupted.  I have seen erroneous labeling as text/plain much more
> often than erroneous labeling as text/html.

RIGHT, good point.  Not hard to fix in a hex editor, except that
you'd have to make sure and remove *both* trailing linefeeds
[or carriage returns], but it would be an added nuisance.  "Dangerous"
depends on how your image viewer, for example, handles corrupt

I have seen the opposite once or twice; attempting to d)ownload
an image file from a dead URL results in a 404 Not Found message
with a [now-inaccurate] .gif suffix.  It caused some weird problems
here, but nothing serious, and I usually catch the "404" statusline

[Some very good ideas snipped, but I'll try them.  Thank you.]

> I wasn't aware that lynx ever prepends the "<!-- X-URL ...>" and
> <BASE ...>" stuff for text/plain documents, but apparently it does
> if one uses 'P'rint from source view!  Just switch using '\' (which
> shouldn't change the appearance at all, but the statusline will
> indicate source view), then 'P'.  Now this is probably unintentional
> (overlooked because source view of plain text isn't really meaningful),
> but seems to be exactly what you want.

Heh, thanks!  I never tried that. . .  Well, I *had*, in v2.7.1
but it didn't work.  Apparently, there was once a provision against
source-viewing plaintext, but it was either removed or broken
in later versions.  When I try "\" in MacLynx it says "text/plain.
D)ownload or C)ancel?" [or something to that effect].  Oddly
enough, c)ancel drops you into the parent directory or previous
document instead of staying with the text file.

The newer Lynx on's server doesn't have this "feature",
thankfully.  :-)  But one problem there is that when you save
local files, you generally want them to *be* local; on your own
HD, not your login dir on the server.  However, using Print to
Screen and then copying/pasting into a local text editor fixes

> > By the way, what's the "X-URL:" comment for?
> "X-URL:" was there first, long before BASE was added IIRC.
> I think it made sense to keep it, given that the BASE URL can
> be different as you note.

Ah, I see.  It also clearly indicates whether this BASE element
was in the original document, or if Lynx added it.  That by itself
would make the comment useful.


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]