CR = <US-ASCII CR, carriage return (13)> LF = <US-ASCII LF, linefeed (10)>
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see appendix 19.3 for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described in section 3.7.
19.3 Tolerant Applications
The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR.
-----Original Message----- From: Don Dailey [mailto:drd@supertech.lcs.mit.edu] Sent: Monday, August 20, 2001 11:08 AM To: pierce@twinforces.com Cc: bump@match.stanford.edu; gtp@lists.lysator.liu.se; gnugo@gnu.org; dave.denholm@insignia.com Subject: Re: [gtp] Re: VC regression failures
When is this really an issue? It's only when you are doing things over a network between platforms, never when you are using "native" software tools.
Is there already a defined convention for doing this? I know these platforms work together all the time over the internet, but I have never taken the time to understand what the low level issues are.
Web pages can be constructed and loaded on all platforms, how are web browsers designed to cope with these issues? I don't know the answer, but I suggest we find out, and do the same.
Don
Date: Mon, 20 Aug 2001 07:35:10 -0700
On Sunday, August 19, 2001, at 08:18 PM, Daniel Bump wrote:
David Denholm wrote:
My inclination would be to define that GTP uses LF for end of line,
and
treats CR as a whitespace character. Provided the protocol also defines that trailing whitespace will be ignored (which impacts things like sending filenames as parameters, since they could end in spaces). in space, for example) So then either CRLF or LF will work fine.
A disadvantage of this scheme is that printf("gtp response\n") would be broken on Macintosh, since CR is the Macintosh newline.
Mac C compilers output \r in place of \n.
PC C compliers output CRLF.
Easier to just execute when either a CR or LF is received, and allow the "null" command that lies between CRLF.
Pierce
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
On Monday, August 20, 2001, at 08:21 AM, Cabrera, Alan wrote:
CR = <US-ASCII CR, carriage return (13)> LF = <US-ASCII LF, linefeed (10)>HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see appendix 19.3 for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described in section 3.7.
19.3 Tolerant Applications
The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR.
That's not really relevant, as thats the protocol, which probably just sends CRLF always because its broken for platforms that use CR as a line terminator.
As for the browser, the HTML interpreter collapses all white space into a single space before interpreting it, so line endings are basically turned into spaces, and whether CRLF generates one space or two before being collapses doesn't matter. That's how it can deal with .html files created on 3 different platforms.
In our case, I say we just accept CR or LF as a line terminator, and we ignore zero length lines such as occur between a CRLF pair. Then all platforms will work.
Pierce
-
Cabrera, Alan -
Pierce Wetter