incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: Appending "\n" and pretty printing output from the command line using curl (with a smidge of python)
Date Fri, 22 Aug 2008 11:52:17 GMT
On Fri, Aug 22, 2008 at 09:42:08AM +0200, Jan Lehnardt wrote:
> If anything, we should be talking HTTP by the spec. RFC 2616 nowhere states
> that the the message or the body part of a request should end in a newline.

This is incorrect. RFC2616 explicitly states that the entity-body of a HTTP
response should be delimited according to the rules of it's media type.

  2.2 Basic Rules

  ...

  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.

Please see my previous email for the exact details of the POSIX specification
for text mode files and canonical IO processing.

UNIX applications WILL choke on files that do not end in a proper delimiter.

> Adding a newline would effectively alter content which in turn potentially
> breaks clients.

This is a non sequitur. We are only proposing to add a newline character to JSON
media types, and so this will have absolutely no harmful effect on clients.

> We could try and guess if a "human user-agent" is making the request but I
> doubt that we can make that reliable.

Perhaps you are conflating the issues here. It's not about prettifying the
output for humans, it's about correcting the text file format per the standards
so that the regular UNIX toolchain can process it without problems.

Best,

-- 
Noah Slater, http://people.apache.org/~nslater/

Mime
View raw message