lynx-dev
[Top][All Lists]
Advanced

[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
=========================================================================

reply via email to

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