In article <6b19e$4422ba19$513a1b62$29466@news.versatel.net >, "Jean Pion" <jean_pion@hotmail.com> writes:
>
> Currenly I'm trying to decode a html response.

You're trying to process an *HTTP* response. It has nothing to do
with HTML, though the content-body may be HTML text.

> I know that the headers are separated by a CR LF.

Not quite. HTTP defines CRLF as the end-of-line marker outside the
content-body, but it provides for header continuation lines (RFC 2616
2.2), so CRLF does not always indicate the end of a header field
value.

> After the headers there is an emty line.
> Then the message body starts.

Specifically, the HTTP header is terminated by CRLF CRLF, where the
first CRLF marks the end of the final header field. If there is a
content-body, it follows immediately after the second CRLF.

> Now my message body appears to begin with a hex number followed by CR LF

That's very likely the "chunked" transfer-coding, which is described
at length in RFC 2616.

> I can not find this in the rfc. Could this be the message length?

No, it's the chunk length. See RFC 2616 3.6.1. Note that all
HTTP/1.1 implementations must support the chunked transfer-coding; if
you're writing your own HTTP user agent for a special purpose it's
often easier to just use HTTP/1.0. (General-purpose user agents
should use HTTP/1.1 and be at least conditionally-compliant.)

--
Michael Wojcik michael.wojcik@microfocus.com

How can I sing with love in my bosom?
Unclean, immature and unseasonable salmon. -- Basil Bunting