Thanks for your prompt response.
Because the chunk-extensions are part of the buffer but doesn't count as
part of the chunk size the current implementation has to be changed.

I'm not sure what do you mean with:

> 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.

I'm not familiar with all the internals of libcurl, but a good approach
maybe to separate the actual payload buffer and the headers ( chunk size,
chuck extensions, chunk delimiter =CRLF ). And compose the message at the
time you write it to the wire.

Inca

On Fri, Aug 23, 2013 at 3:27 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> 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.
>
> --
>
> / daniel.haxx.se
> ------------------------------**------------------------------**-------
> List admin: http://cool.haxx.se/list/**listinfo/curl-library<http://cool.haxx.se/list/listinfo/curl-library>
> Etiquette: http://curl.haxx.se/mail/**etiquette.html<http://curl.haxx.se/mail/etiquette.html>
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-08-23