httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <di...@webweaving.org>
Subject Re: OS/390 Translation
Date Fri, 03 Dec 1999 21:19:23 GMT

On Fri, 3 Dec 1999, Martin Kraemer wrote:

> On Fri, Dec 03, 1999 at 09:16:37AM -0700, pg@sweng.stortek.com wrote:
> > If it is necessary to change Martin's design, it will probably
> > to be necessary to rebuild with strcat() all strings now
> > containing '\012'.
> 
> Actually, having \n and \r in place of \012 and \015 thruout the code
> would probably have resulted in an easier port to EBCDIC machines
> (it would avoid the os_toascii_strictly kludge).
> 
> On the socket level, we *ALWAYS* have to transmit '\012' and '\015'.
> 
> But changing '\012' to '\n' and '\015' to '\r' everywhere would break
> on ASCII based systems where  ('\n' != '\012') or ('\r' != '\015')
> (when it's an ASCII system, there's no implied additional conversion
> step which could fix the different representations. On EBCDIC, we
> have this translation step).
> 
> That is for instance the case with Macintosh and similar systems
> (where '\n' == '\015', like in OS-9/68k). The reason why explicit
> '\012' and  '\015' were coded in the first place was to avoid
> protocol errors caused by such a differing ASCII implementation.
> 
I concur here. 

On Mac and Acorn you really cannot rely on \r and \n to have the same
octed value as required by the RFC's defining the wire side of HTTP. They
have the same semantics of course. But that is not wat the RFC require. It
talks about octed stream's, and that is the value of that byte.

Dw


Mime
View raw message