Re: LYNX-DEV Bug in Lynx 2-7-2 with web500gw

[Ric Miller ACNS]

On Tue, 20 Jan 1998, Foteos Macrides wrote:

> Date: Tue, 20 Jan 1998 21:11:23 -0500 (EST)
> From: Foteos Macrides <address@hidden>
> Reply-To: address@hidden
> To: address@hidden
> Subject: Re: LYNX-DEV Bug in Lynx 2-7-2 with web500gw
> 
> 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
> 
 
   I can accept this.

 
>>>> 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.  

  This is good to know.  I was not told about this before.

> 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.  

  Gee, I set the User-Agent header to the exact header at 2.5 and it is
  still not returning the same html.  This seems to indicate that the
  server is not responsible for the problem.

> 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.  

  Or a bug or feature of the client.

> 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
 
   I do not believe I demanded anything from anyone.  I am  looking  for  a
   response  from  someone  that  might  have a simple explanation for this
   behavior.  This list appears to be the only means to report bugs  or  to
   get  help  with the lynx installation.  I was hoping someone with a good
   knowledge of the lynx code(like those that wrote it) might be  listening
   and  could  tell  me  if  this  is a lynx problem before I go off on the
   web500gw tangent.  

   Ric Miller (address@hidden)
   Academic Computing & Networking Services