cURL / Mailing Lists / curl-library / Single Mail


Re: Possible tftp Problem

From: Daniel Stenberg <>
Date: Tue, 29 Mar 2011 10:57:59 +0200 (CEST)

On Tue, 29 Mar 2011, Colin Blair (colblair) wrote:

> When I code an application with a read callback function and initiate curl I
> see the callback function get called with a buffer size of 512 bytes. If I
> return a value of 512 bytes the callback function will be called until I
> return a value of less than 512 bytes. However, once I return a value less
> than 512 bytes, the callback function is never called again.

Aaah, indeed. Yes, you've correctly identified a flaw, or should we call it a
limitation in the way libcurl uses the read callback and how it does TFTP.

> According to the curl documentation:
> "When you call curl_easy_perform(3) this time, it'll perform all the
> necessary operations and when it has invoked the upload it'll call your
> supplied callback to get the data to upload. The program should return as
> much data as possible in every invoke, as that is likely to make the upload
> perform as fast as possible. The callback should return the number of bytes
> it wrote in the buffer. Returning 0 will signal the end of the upload."
> Is this a bug in the tftp support for curl? I would have expected the
> callback function to be called by curl the same way as it is for the file:
> protocol.

There obviously is a difference, but it was never explicitly intended - only
accidentally introduced.

The reason is that after the read callback returns back to libcurl, the
contents is used as-is in the TFTP packet. With TFTP, all packets *except for
the last one* are fixed-size and you cannot send a short one in the midst of a

So, in the short-term we should document that this is in fact how libcurl
works when doing TFTP uploads.

For the long-term, we can of course consider changing the way libcurl works.
But it would then have to basically call the read callback again if you return
short, as it can't send off a TFTP packet until the block-size is filled up.

List admin:
Received on 2011-03-29