Re: That patch I had...

• Date: Fri, 19 Jan 1996 09:26:39 PST
• From:
  nop@nop.com (Jay Carlson)
• cc: nop@nop.com, moo-cows@parc.xerox.com, jft@psychology.nottingham.ac.uk
• In-reply-to: Your message of "Fri, 19 Jan 96 07:02:47 PST." <9601191455.AA04607@ukhayq.CV.COM>

Mark Bowyer wrote:
> Jay wrote:
>> Mark wrote:
>>> As an additional, thanks to Pavel for adding all we need to control
>>> the sending of \r for better Web displays, serving binaries from the
>>> MOO as an HTTPD (with the addition of FUP) and possibly building a
>>> MOO-FTP server/client object, without having to hack the server for
>>> it.

>> I'm confused; I guess the only advantage I see to \r is octet-stream
>> formats like gif.  Do you use selective \r elsewhere?

> As I've explained before, using our MOO as an HTTPD to a Mac seems
> to cause double spacing of lines.  By removing the \r from all
> lines, we fix this, and so we have been tweaking the server so we
> can control when we ouput \r\n and when we just use \n.  It works.

That's interesting; I haven't noticed that kind of behavior from JHM
at least.

I'm gonna quote from the current http spec draft, 

http://www.w3.org/pub/WWW/Protocols/HTTP1.0/draft-ietf-http-spec.html#TextCanonicalization

   [...] However, HTTP modifies the canonical form requirements for
   media of primary type "text" and for "application" types consisting
   of text-like records.

   HTTP redefines the canonical form of text media to allow multiple
   octet sequences to indicate a text line break. In addition to the
   preferred form of CRLF, HTTP applications must accept a bare CR or
   LF alone as representing a single line break in text
   media. [non-ascii sets exception elided, mime headers note too]

   A recipient of an HTTP text entity should translate the received
   entity line breaks to the local line break conventions before
   saving the entity external to the application and its cache;
   whether this translation takes place immediately upon receipt of
   the entity, or only when prompted by the user, is entirely up to
   the individual application.

So there's no reason why you should be getting double-spaced lines
from CRLF, as long as you're speaking text/* or a known application/*.
Do you have an example URL where this problem would occur?  Perhaps
you're having MIME problems instead.

>> Have you noticed a real speedup from listassoc?  Like one that's
>> documentable?  I'm always interested in going after hotspots...

> There is a standard patch in the patch FTP site for replacing
> listassoc and listiassoc with builtins.  We've been using them since
> 1.7.8p4 to 1.8.0a5 with no problems and a lot better performance.

Can you actually document lower CPU usage?  I know it gets you lower
tick usage...

Jay Carlson
nop@nop.com    nop@kagoona.mitre.org

Flat text is just *never* what you want.   ---stephen p spackman

• Re: That patch I had...
• From: mark@ukhayq.cv.com (Mark R. Bowyer)

• Prev: Re: That patch I had...
• Next: Re: That patch I had...
• Index: MOO-cows
• Thread: MOO-cows