[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV Bug in Lynx 2-7-2 with web500gw
From: |
Foteos Macrides |
Subject: |
Re: LYNX-DEV Bug in Lynx 2-7-2 with web500gw |
Date: |
Tue, 20 Jan 1998 21:11:23 -0500 (EST) |
Ric Miller ACNS <address@hidden> wrote:
>On Fri, 16 Jan 1998, David Woolley wrote:
>
>> Date: Fri, 16 Jan 1998 08:04:16 +0000 (GMT)
>> From: David Woolley <address@hidden>
>> Reply-To: address@hidden
>> To: address@hidden
>> Subject: Re: LYNX-DEV Bug in Lynx 2-7-2 with web500gw
>>
>> >
>> > After installing lynx 2-7-2 the following url
>> >
>> > http://directory.colostate.edu:1411/o=Colorado State University, c=US
>>
>> As you more or less point out below, this is not a URL.
>
> This worked at 2-5. It seem to be valid then. It works with Netscape
> 3.0 and all other versions as far as I know.
You are making the very serious mistake of equating "validity"
with the empirical behavior of particular browsers. What is "valid" or
not should be based on standards documents generated by the responsible
organization. In the case of URLs (a subset of URIs) it is the IETF.
Raw spaces have been invalid in URLs/URIs since the beginning of the
Web and in all IETF standards documents. The most current draft is:
http://www.ics.uci.edu/pub/ietf/uri/draft-fielding-uri-syntax-01.txt
which says:
[...]
2.4.1. Escaped Encoding
An escaped octet is encoded as a character triplet, consisting
of the percent character "%" followed by the two hexadecimal digits
representing the octet code. For example, "%20" is the escaped
encoding for the US-ASCII space character.
[...]
2.4.3. Excluded US-ASCII Characters
Although they are disallowed within the URI syntax, we include here
a description of those US-ASCII characters which have been excluded
and the reasons for their exclusion.
The control characters in the US-ASCII coded character set are not
used within a URI, both because they are non-printable and because
they are likely to be misinterpreted by some control mechanisms.
control = <US-ASCII coded characters 00-1F and 7F hexadecimal>
The space character is excluded because significant spaces may
disappear and insignificant spaces may be introduced when URIs are
transcribed or typeset or subjected to the treatment of
word-processing programs. Whitespace is also used to delimit URIs
in many contexts.
space = <US-ASCII coded character 20 hexadecimal>
[...]
>>> At 2-7-2 THE SEARCH BOX APPEARS AT THE BOTTOM(this is not correct).
>>
>>> I do not understand
>>> why the search box is moved to the bottom. This appears to have something
>>> to do with the web500gw detecting what kind of client is talking to it and
>>> changing the source html accordingly?
>>
>> That's rather strange, as I don't believe the standard web500gw package is
>> all that sophisticated in that sort of area, although I haven't experimented
>> with it. The source code is available, and you should probably follow up on
>> the IETF directory deployment mailing list, as the original LDAP list seems
>> to have died.
>
> I also find it rather strange that this would behave differently based on
> this client. I do not have time to look through source code that appears
> to be working on every other client I try. It seems to me someone should
> be able to tell me why it works one way with lynx 2.5 and another way
> with 2.7.2.
You already have been told, but seem unwilling to accept it. In
v2.7.2 you can set arbitrary User-Agent header strings via the 'o'ptions
menu. If you set it to that which was used for v2.5 you will get back
the HTML which v2.5 is sent, which further indicates that the User-Agent
header is affecting what HTML that server returns. But there is no way
to know for sure, and to assess whether it's a bug or feature of the server,
without looking at its code. If you don't have the time, by what right do
you demand that others on this list make the time to do it for you? I find
that rather strange -- this is not the LDAP development group.
Fote
=========================================================================
Foteos Macrides Worcester Foundation for Biomedical Research
address@hidden 222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================