in reply to Re^2: Perl LWP Can handle client-transfer-encoding = chunked encoding?
in thread Perl LWP Can handle client-transfer-encoding = chunked encoding?

No, that's usually not what "chunked" encoding means. It usually means that the response contains more than one file/document and you have to use the appropriate method to separate them.

What you are referring to is a partial response, which the server is only allowed to send if you explicitly ask for it. This is commonly used when resuming a large download or seeking in streamed media. (See "range request".)

-- FloydATC

Time flies when you don't know what you're doing

  • Comment on Re^3: Perl LWP Can handle client-transfer-encoding = chunked encoding?

Replies are listed 'Best First'.
Re^4: Perl LWP Can handle client-transfer-encoding = chunked encoding?
by noxxi (Pilgrim) on Jan 17, 2015 at 08:07 UTC
    Transfer encoding 'chunked' was introduced with HTTP version 1.1 and is used when the length of the content is not known up-front, so that no 'Content-length' header can be given. Instead the content is sent in several chunks, each prefixed by the length of the chunk.
    It is not related to content-encoding like gzip and both can be used together. It is also not related to a content consisting of multiple parts. In this rarely used cases instead a Content-type of multipart/whatever is used and the client has to split the content by the given boundary, similar to multipart MIME messages in mails.
    Any HTTP client claiming support for version 1.1 (like LWP) must support this transfer encoding and there is no way to tell the server not to use it except switching to HTTP/1.0. The Accept-Encoding header only affects the accepted values for Content-Encoding (i.e. compression), not Transfer-Encoding.
[reply]

In Section Seekers of Perl Wisdom