cURL / Mailing Lists / curl-library / Single Mail


Re: how to implement chunk extensions

From: Daniel Stenberg <>
Date: Fri, 23 Aug 2013 12:27:10 +0200 (CEST)

On Thu, 22 Aug 2013, Inca R wrote:

> I need to implement chunk extensions when sending POST/PUT/DELETE requests
> from my client using libcurl. I realize that currently libcurl doesn't
> support it. I was looking at the code and found that the write callback to
> get chunk data rom the client application is in the transfer.c file.

The read callback you mean. libcurl reads from the app when it wants to send
it off.

> Before I start doing any code or thinking, maybe someone else implement
> this?

I'm not aware of any such effort. There is previous (non-merged) work on
getting chunked trailer support but I've not seen anyone try getting chunked
extension support done.

> What will be the best way to implement ? Adding an new callback to get chunk
> data an extension headers ?

That's certainly _one_ way to do it that would be fairly easy to implement I
think. Would that be a way that would work for you? I figure then it would be
called after the read callback (chunk) for which the extension would be
associated? Or would it be called before?

An alternative approach would be to introduce a function that can be used from
within the read callback that sets the extension. Like a setopt() version.

> One of the problems is that the library assumes there are no extensions,

Well, the library doesn't support any extensions so it is quite right to
assume so...

> and provides a buffer right after the chunk size space + CRLF ( 10 bytes )
> and on return it adds the CRLF. If there is any extensions this will break.

Obviously adding support for extensions implies that logic needs to be fixed
so that extensions can be included. As there's really no length limit to how
larger an extension can be, that naive approach we have now that just deducts
the maximum chunk-"header" size from the buffer size before calling the
callback cannot be used like that as for ridiculously large extensions there
would be no room left for data!

Still, I think working out a sensible API for it would be a good first step,
and then we can work on getting the implementation done and working. It
shouldn't be too hard to write up a couple of test cases with the curl test
suite to verify this functionality.

List admin:
Received on 2013-08-23