[gopher] Existing \n.\n behavior
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Testing \n.\n in the middle of a file
-------------------------------------
Clients:
UMN gopher: no special behavior
lynx: no special behavior
netscape4: no special behavior
konqueror: no special behavior
IE 5.1/mac: aborts transfer at \n.\n
Testing \n.\n at the end of a file
----------------------------------
Clients:
UMN gopher: strips it
lynx: no special behavior
netscape4: no special behavior
konqueror: no special behavior
IE: strips it
Testing no \n.\n at all
-----------------------
Clients:
UMN gopher: no problems
lynx: no problems
netscape4: no problems
konqueror: no problems
IE: no problems
UMN gopherd server behavior
---------------------------
Normal file (no \n.\n in it): adds \n.\n at end
File with \n.\n in middle: passes it through, adds \n.\n at end
File with \n.\n at the end: passes it through, adds another \n.\n
From this, we can conclude:
1. Since the majority of the Ineternet's gopher servers are presumably
running UMN gopherd, we know that they are not doing any special
escaping of \n.\n.
2. Of the clients tested, only Internet Explorer did anything special
with \n.\n occuring in the middle of a file. All other clients passed
it through.
3. Only UMN gopher and IE strip \n.\n at the end of a file. Only IE has
trouble with \n.\n in the middle of the file.
Therefore:
4. Abolishing \n.\n from being added by servers will have zero negative
impact on tested clients.
5. Abolishing all \n.\n behavior will resolve ambiguity about \n.\n
occurring at the end of existing text files in UMN gopher immediately
(and hopefully IE soon). It will also resolve ambiguity about \n.\n in
the middle of files in IE.
6. Clients expecting \n.\n at the end of a file but not getting it are
fine. (Old client, new server scenario)
7. Clients not expecting \n.\n at the end of the file but getting it
anyway will simply display a "." at the end. All but UMN gopher and IE
do this already anyway. (New client, old server scenario)
I conclude that immediately abolishing all special \n.\n behavior from
all software under the control of this group would have a net positive
impact on gophers net-wide, even considering the large installed base of
legacy software.
-- John
- [gopher] Existing \n.\n behavior,
John Goerzen <=
|
|