Subject: Hello I've just found 2 more typographical error on RFC 2616

From: "WooJin Chung" <[email-masked]>
Date: Tue, 7 Nov 2006 14:22:29 +0900

Hi this is the same person who sent an e-mail about typographical errors on
"RFC 2616, 4.4, Message Length."

As I read through, I've found 2 more errors on "RFC 2616 14.3Accept-Encoding."

Here's the paragrah.

14.3 Accept-Encoding

The Accept-Encoding request-header field is similar to Accept, but restricts
the content-codings (section 3.5) that are acceptable in the response.

       Accept-Encoding  = "Accept-Encoding" ":"

                          1#( codings [ ";" "q" "=" qvalue ] )
       codings          = ( content-coding | "*" )

 Examples of its use are:

       Accept-Encoding: compress, gzip
       Accept-Encoding:
       Accept-Encoding: *
       Accept-Encoding: compress;q=0.5, gzip;q=1.0
       Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

As you can see, Accept-Encoding has to consist of 1 or more ( codings [ ";"
"q" "=" qvalue ] ).
And if you see the definition of '#', you can find out that null element
can't be counted, and this means you can't just leave a blank after
Accept-Encoding: .
But in the given example, there exists a blank space and this is considered
as a correct one.

The second error is at the last line. Right after the semi-colon, there
can't be a space(SP) by definition, but there actually is in the example.

I don't know whether you'll see this or not since there's no way to check,
but I hope the errors get fixed.

WooJin Chung