Network Newline

[Travis Parks]

Hello:

I am working with Boost Asio. Their examples create newlines using "\r\n". My understanding was that \n was translated to whatever the newline symbol for the system was. My concern is that on Windows, this code will be spit out as \r\r\n instead of \r\n. Is this the case? Is there a way to get \r\n specifically? I wan't sure if I'd have to resort to \x0D\x0A.

Thanks,
Travis Parks

 

[Geoff]

Hello:

I am working with Boost Asio.
Their examples create newlines using "\r\n". My understanding
was that \n was translated to whatever the newline symbol for
the system was. My concern is that on Windows, this code will
be spit out as \r\r\n instead of \r\n. Is this the case? Is
there a way to get \r\n specifically?
I wan't sure if I'd have to resort to \x0D\x0A.

It would be great if you could find the newline to put it in your
browser when posting from Google Groups.

I don't know about the Boost library but under Windows a file is open
in text mode where "\n" is output as "\r\n" and "binary" mode where
it's not.

For compatibility, I'd EXPECT Boost to isolate me from that detail.

Outputting "\x0d\x0a" is identical to "\r\n".

 

[BGB]

Hello:

I am working with Boost Asio. Their examples create newlines using "\r\n". My understanding was that \n was translated to whatever the newline symbol for the system was. My concern is that on Windows, this code will be spit out as \r\r\n instead of \r\n. Is this the case? Is there a way to get \r\n specifically? I wan't sure if I'd have to resort to \x0D\x0A.

"\n" only becomes "\r\n" when written to a file which was opened in text
mode (or, potentially, when writing to "stdout" or similar).

otherwise, no special treatment is given to "\n", which simply
represents a newline character.


or such...

 

[Travis Parks]

It would be great if you could find the newline to put it in your
browser when posting from Google Groups.

Sorry. I get auto text wrapping in the browser. I'll try to remember.

I don't know about the Boost library but under Windows a file is open
in text mode where "\n" is output as "\r\n" and "binary" mode where
it's not.

For compatibility, I'd EXPECT Boost to isolate me from that detail.

Outputting "\x0d\x0a" is identical to "\r\n".

When you say identical, do you mean \x0A and \n have the same semantics?
Is there a way to spit out \n without the language expanding it on Windows?

 

[Travis Parks]

Oh no it isn't.

On most machines 0x0d is carriage return, and 0x0a is line feed. C
systems tend to use line feed as new line - but as has been pointed out,
Windows systems don't.

Windows will often see 0d 0a (or \r\n) as TWO new lines, *nix as ONE.

More importantly there are still a lot of mainframes out there using
EBCDIC character codes, and while 0x0d happens to be CR in both, EBCDIC
0x0a is "Repeat" (or so Google tells me...) and I have no idea what that
means.

Stick to \r\n. The worst that happens is a blank line.

Andy

I wonder if an extra newline will cause problems with the HTTP format?

 

[Travis Parks]

"\n" only becomes "\r\n" when written to a file which was opened in text
mode (or, potentially, when writing to "stdout" or similar).

otherwise, no special treatment is given to "\n", which simply
represents a newline character.


or such...

So, what are the effects when writing to a socket?

 

[Victor Bazarov]

[..]
The HTTP protocol requires that in the HTTP header the newlines must be
encoded as a series of two bytes with numeric values 13 and 10. The
simplest way to create these bytes in current widespread implementations is
to use "\r\n". Don't know or care about EBCDIC machines.

Uh... If chars with values 13 and 10 (decimal) are expected, \0xd\0xa
is the most straightforward *and* portable way to output them, EBCDIC or
not.

V

 

[Fred Zwarts \(KVI\)]

"Victor Bazarov" wrote in message news:[email protected]...

[..]
The HTTP protocol requires that in the HTTP header the newlines must be
encoded as a series of two bytes with numeric values 13 and 10. The
simplest way to create these bytes in current widespread implementations
is
to use "\r\n". Don't know or care about EBCDIC machines.

Uh... If chars with values 13 and 10 (decimal) are expected, \0xd\0xa is
the most straightforward *and* portable way to output them, EBCDIC or not.

And the most readable and self-documenting, I would say.

 

[Nobody]

Uh... If chars with values 13 and 10 (decimal) are expected, \0xd\0xa
is the most straightforward *and* portable way to output them, EBCDIC or
not.

HTTP requires that the headers are encoded in ASCII, so there's really no
difference between e.g.

"HTTP/1.1 200 OK\r\n"
and:
"HTTP/1.1 200 OK\x0d\x0a"

If the string is output as ASCII, either will work; if it's output as
EBCDIC, neither will work. Encoding the entire string using hex escapes
would be silly; HTTP implementations which are intended to work on
non-ASCII systems invariably have functions to perform the necessary
conversions.

As the HTTP payload may be arbitrary binary data, the interface between
the application and the TCP connection must not perform any EOL
conversions.

 

[BGB]

[..]
The HTTP protocol requires that in the HTTP header the newlines must be
encoded as a series of two bytes with numeric values 13 and 10. The
simplest way to create these bytes in current widespread
implementations is
to use "\r\n". Don't know or care about EBCDIC machines.

Uh... If chars with values 13 and 10 (decimal) are expected, \0xd\0xa is
the most straightforward *and* portable way to output them, EBCDIC or not.

if the system is using EBCDIC, one has much bigger problems here than
which character values are used to encode the newline...

(in effect, you will need functions to marshal the strings, in which
case, you would probably still use "\r\n", with the string-marshaling
function converting them as appropriate).

 

[Jorgen Grahn]

I wonder if an extra newline will cause problems with the HTTP format?

Don't wonder -- check the relevant RFCs. I bet the answer is 'yes'.

/Jorgen

 

[Jorgen Grahn]

"Victor Bazarov" wrote in message news:[email protected]...

[..]
The HTTP protocol requires that in the HTTP header the newlines must be
encoded as a series of two bytes with numeric values 13 and 10. The
simplest way to create these bytes in current widespread implementations
is
to use "\r\n". Don't know or care about EBCDIC machines.

Uh... If chars with values 13 and 10 (decimal) are expected, \0xd\0xa is
the most straightforward *and* portable way to output them, EBCDIC or not.

And the most readable and self-documenting, I would say.

I suppose the "don't know or care" means P.H. is in a situation
similar to mine: his code is /already/ specific for the Unix socket
API (or maybe the Windows one). It's customary on Unix to refer to
that sequence as \r\n or CR-LF.

I'd have to think harder to interpret "\0xd\0xa" -- along the lines of
"J comes before M in the alphabet, so that would mean M-J, or ^M and a
newline, which is the DOS line ending and also the traditional socket
line ending ... okay, it's probably correct."

/Jorgen