lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV X-URL header field


From: Foteos Macrides
Subject: Re: LYNX-DEV X-URL header field
Date: Mon, 24 Nov 1997 21:18:01 -0500 (EST)

Uzi Paz <address@hidden> wrote:
>On Sun, 23 Nov 1997, Al Gilman wrote:
>
>> to follow up on what Uzi Paz said:
>> 
>> > Any comments about using "X-URL" equivalent for mailing the stripped text
>> > version via the "print" command? I don't know of any apropriate header
>> > field, but it seems that "X-URL:" is definitly not good. .. [snip]
>> 
>> Can you be a little more specific as to what problem is caused by the
>> way it works now?
>
>I see no problems _at_the_moment_ , because as far as I know it is not
>used by any automate.
>
>I neither believe that you should change it at the moment. I do, however
>believe that there should be a standard for dealing with such references -
>with a well defined meaning to each header-field.
>
>In principle, it is better to avoid such multipurpose header fields. 
>
>Many non-standard header fields became de-facto standard fields, because
>they were used in one program and then in another etc.
>At some point one wishes to extend software to use these header fields,
>but as there is no single meaning its not possible, and one has to use a
>different header field. In the case of X-URL, because it has the "X-",
>then if such a field becomes an Internet standard, it will have a
>different name.
>
>At the moment, I mainly wish to have a clearer picture of this subject.
>
>Anyway, I wish to thank you and Fote for the info.

        Just to be sure the picture indeed is clear, here's an example
of what is mailed via the 'p'rint menu when source ('\') was toggled
on before issuing that command:

Return-path: <address@hidden>
Received: from SCI.WFBR.EDU by SCI.WFBR.EDU (PMDF V5.0-4 #19169)
 id <address@hidden> for address@hidden; Mon,
 24 Nov 1997 20:36:21 -0500 (EST)
Date: Mon, 24 Nov 1997 20:36:21 -0500 (EST)
From: address@hidden
Subject: white.html
To: address@hidden
Message-id: <address@hidden>
MIME-version: 1.0
Content-type: text/html; charset=dec-mcs
Content-transfer-encoding: 8bit
Content-Base: file://localhost/appm$disk/www/lynx271f/src/white.html
Content-Location: file://localhost/appm$disk/www/lynx271f/src/white.html
X-URL: file://localhost/appm$disk/www/lynx271f/src/white.html

<!-- X-URL: file://localhost/appm$disk/www/lynx271f/src/white.html -->
<BASE HREF="file://localhost/appm$disk/www/lynx271f/src/white.html">

[... originally iso-8859-1 document with 8-bit characters converted
     to my Display Character Set (DEC Multinational) and any tabs
     expanded ...]


        The X-URL always is the actual URL used to retrieve the
document.  If it had been an http(s) URL and a Content-Location
header had been included in the response, that value would be
used.  Otherwise, as in this case, it's the same value as for
X-URL.  In this case, of a local file, it so happens that I
mailed myself a test file from a privileged directory.  If
I were to read mail with some new-fangled software which used
the Content-Location value in some manner involving an attempt
to access it, that would fail unless my process had the
appropriate privileges turned on (which I normally have off),
and no other recipient could access it.  That's why I wonder
if it's a good idea to include it when it does not point
to a URL that is accessible via TCP/IP.  Also, even if it
were an http URL, the charset would not be what is in this
actual mailing (dec-mcs), but iso-8859-1, and if the charset
were a factor in the mail software's decision, it still
could be misled by the Content-Type header.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

reply via email to

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