[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
files.
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
alert.
[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 Island.net'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
that.
> > 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.
Patrick
<mailto:address@hidden>
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden