Hrvoje Niksic wrote:
> > This is contrary to the spec which strictly states that
> > content-length must be obeyed and that the user must be notified
> > that something strange happened.
>
> Which spec says that?
Quoting from section 7.2.2 of RFC 1945:
When an Entity-Body is included with a message, the length of that
body may be determined in one of two ways. If a Content-Length header
field is present, its value in bytes represents the length of the
Entity-Body. Otherwise, the body length is determined by the closing
of the connection by the server.
Note: Some older servers supply an invalid Content-Length when
sending a document that contains server-side includes dynamically
inserted into the data stream. It must be emphasized that this
will not be tolerated by future versions of HTTP. Unless the
client knows that it is receiving a response from a compliant
server, it should not depend on the Content-Length value being
correct.
Since wget is an HTTP/1.0 client, its behavior is entirely consistent with
the specification. Noel was probably thinking of RFC 2068, which says:
When a Content-Length is given in a message where a message-body is
allowed, its field value MUST exactly match the number of OCTETs in
the message-body. HTTP/1.1 user agents MUST notify the user when an
invalid length is received and detected.
But until wget is upgraded to be a 1.1 client, it does not need to worry
(much) about RFC 2068. Even after the conversion, the only obvious change
that is needed is to include a message about the invalid length in wget's
output, which most users will probably overlook anyway.
Tony
