[Prev][Next][Index][Thread]

# Re: That patch I had...

- Date: Fri, 19 Jan 1996 09:26:39 PST
- From:
- 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

References:

- 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

Home | Subject Index | Thread Index