Re: lynx-dev Feature Request (not bug)

[Klaus Weide]

On Sat, 18 Dec 1999, Leonid Pauzner wrote:

> At least RFC2141 says '#' and '?' are reserver characters, they should
> be always escaped if the character assumed literally. So '#fragment'
> could be stripped from the suggested file name safely in our case, isn't
> it?

Since we are only dealing with making a suggestion, everything can be
considered as safe - whether it makes much sense or not.

In addition, stripping '#fragment' could make sense.
OTOH, the presence of a '#fragment' may remind the user that he/she
downloaded a file via a URL-reference with a '#fragment' - whatever use
that reminder may be.
Anyway, this thread didn't start with someone having a problem with the
presence of '#fragment' in the suggested filename - but with someone
having a wish about hadling such a file once it exists (the filename
may or may not have been accidental).

> (There are URL, URI, URN... I may be unaware of a tiny differences).

We can consider URL and URI as equivalent for all practical purposes
and forget about URN.

> > (Your logic "since we have a fragment, it must be text/html" is wrong.
> > Let me give you a link to 'd'ownload:
> > <ftp://ftp.digital.com/pub/net/infosys/lynx/current/PROBLEMS#blah>.

Let's be a bit strict in our terminology.  (But not so strict that we pay
attention to the difference between URL and URI. :) )

This is a URL-reference:

   ftp://ftp.digital.com/pub/net/infosys/lynx/current/PROBLEMS#blah

It is not a URL - sloppy usage of the term "URL" in may places, where
what's meant is really "URL-reference", notwithstanding.

This is a URL:

   ftp://ftp.digital.com/pub/net/infosys/lynx/current/PROBLEMS

(it also is a URL-reference.)
It is the URL in the firstmentioned URL-reference.

> You mean file name is "PROBLEMS", not "PROBLEMS#blah" - right?

You can append a fragment to any URL.  It doesn't change "the URL"
of the resulting URL-reference.  It still identifies the same "resource".
As far as any network (or local, i.e., "file") protocol for retrieving
the resource is concerned, there is no difference.

Whether the appended '#fragment' makes any difference depends on the
MIME type and the client.  For types other than text/html, we just ignore
it.  But we still keep it as part of the URL-reference (sloppily called
"URL") by wich the document is identified on the INFO screen, in the
HISTORY list, etc.

> > Can you see from the URL-reference whether that is text/html?)

So, even though a URL-reference with a '#fragment' may not make much
sense for anything but text/html - the fragment is generally ignorable -
we still accept it, so resources that are (for example) text/plain may
still be identified by a URL-reference-with-fragment (perhaps by
mistake), so we cannot deduce from the presence of a '#fragment' with
certainty that we are dealing with text/html.

The presense or absense of '#fragment' in a URL-reference, by itself,
certainly does not change the nature of the resource identified by the
URL, in particular, it does not change its media type.

Now, a file with the *filename* "PROBLEMS#blah" is something completely
different.  The URL to identify such a file will end in "PROBLEMS%23blah".
This should be apparent in Lynx.

If you enter "g PROBLEMS#blah", or start lynx with `lynx PROBLEMS#blah',
and end up being shown the contents of the file "PROBLEMS#blah" (i.e.
a resource identified by a .../PROBLEMS%23blah URL), instead of being
shown the contents of the file "PROBLEMS" - well that's guessing.

Whew.

   Klaus