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 <[email protected]> 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
