Re: comments in HTTP headers

> They're a pain.  They're also ill-specified.

Pain yes, ill-specified no.

> Section 4.2 has a definition of ctext that differs from RFC 822,
> which also allows \ escapes of ( and ).

Yep.  When I wrote the initial specification of headers and comments,
I decided that allowing \ to mean escape would break too many existing
parsers.  This is still my opinion, though if a consensus says otherwise
I will change the draft.

> Also I'm unclear on which has precedence in HTTP, a comment or a
> blank line in the header.  In other words, how do I parse this:
> GET / HTTP/1.0
> Accept: text/basic (this comment
> will include a blank
> [blank line]
> line)
> Accept: text/html
> [blank line]
> where "[blank line]" is what it says.

Meaning what?  Only an *empty line* ends the headers of a message,
and an empty line is not allowed in a comment.  A line containing
space or HTAB is not an empty line.

 ....Roy T. Fielding  Department of ICS, University of California, Irvine USA

p.s.: Conference Hell is upon us all -- I am just now getting through the
      mail amassed during the IETF trip, and am now about to embark on a
      two-week trip through California, Oregon and Washington
      (WebWorld and ICSE-17).  Henrik is in Denmark as well, so don't be
      surprised if mail goes unanswered for a while.

Received on Monday, 17 April 1995 18:35:17 UTC