RE: RFC 2616 Errata: Misc. Typos

Oops, I missed one...

> I've collected several typos; instead of sending out one mail for each,
> I've decided to just lump them all together in one message. Enjoy!

> 1. Section 7.1, page 42:

> Some of this metainformation is <ins>"</ins>OPTIONAL<ins>"</ins>; some
> might be <ins>"</ins>REQUIRED<ins>"</ins> by portions of this
> specification.

> 2. Section 13.13, page 99:

> Even though sometimes such resources ought not <del>to</del><ins>be</ins> > cached, or ought to expire quickly, user interface considerations may
> force service authors to resort to other means of preventing caching (e.g.
> "once-only" URLs) in order not to suffer the effects of improperly
> functioning history mechanisms.

> 3. Section 14.18, page 124:

> The field value is an HTTP-date, as described in section 3.3.1; it MUST be
> sent in <ins>the </ins>RFC 1123 [8]<del>-</del><ins> </ins>date format.

> 4. Section 14.23, page 129:

> A client MUST include a Host header field in all HTTP/1.1 request
> messages<del> </del>.

> 5. Section 14.32, page 137:

> Note: because the meaning of "Pragma: no-cache<ins>"</ins> as a
> response<del> </del><ins>-</ins>header field is not actually specified, it
> does not provide a reliable replacement for "Cache-Control: no-cache" in a
> response<ins>.</ins>

> 6. Section 15.6, page 155:

> HTTP/1.1<del>.</del> does not provide a method for a server to direct
> clients to discard these cached credentials.

7. Section 2.1, page 15:

At least one delimiter (LWS and/or<del>

<del><ins> </ins>separators) MUST exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token.


-- Travis