Re: comments in HTTP headers

At 1:19 AM 4/18/95, Rich Salz wrote:
>>I suppose some of the value is in making the specification agree more
>>with MIME and USENET so that shared code and cross-protocol gateways
>>work more transparently. I really doubt we _need_ the full glory
>>of RFC822 comments most of the time.
>Usenet doesn't allow the full glory of 822 either.  In general, Usenet
>doesn't allow comments except in a particular format for From lines,
>and *sort of* single-word unknown timezones.
>I'd drop comment support unless you use a really limited subset of what 822
>allows.  Doing this still allows you to re-use all that wonderful existing
>822-parsing code, but makes it easier on those writing from scratch.

I'd like to second this. While there do seem to be a few instances where
comments in HTTP headers make sense, HTTP is generally a machine-readable
protocol only and general purpose human-readable comments serve little
purpose in the protocol at large.

Forcing the widespread implementation of a syntactic feature of limited
value is burdensome at best, especially on custom parser authors as Rich
points out. And frankly, there are several of those because of the legal
implications of reusing the "common" code base in commercial apps. Many
HTTP authors simply cannot afford to risk reusing existing code and expect
to retain copyright and ownership.

If comments are necessary in name-related fields (user, server, agent),
then perhaps the syntax should be specified only for those fields. Random
appearances of comments throughout the header seem to be of little utility
and present some difficult recoding problems at first glance (at least for
my cheesey little HTTP parser!)

Chuck Shotton                                                   "I am NOT here."

Received on Tuesday, 18 April 1995 04:29:09 UTC