> 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
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>
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.