@bagder I'd like to see this feature get in if possible, I didn't realize it didn't make it in last round. I already took a look back then and suggested some changes at https://github.com/jay/curl/compare/master...jay:tftp_no_options?expand=1. You said you were going to help with a test case and I had one reservation regarding blocksize:

Now that we're not sending options (tsize, blksize, timeout), someone will need to check that there is not any code that depends on any of those being sent. As far as I can tell no but someone experienced in this protocol may want to take a look. The blocksize for example appears will default to 512 so even if a user specifies a bigger blocksize and the server doesn't return a blocksize 512 will be used.

That's probably fine, but I'm not 100%.

@jay About your reservation:
To my knowledge there is no back channel for option information. So even if the application was using the option to change the BLKSIZE it would never know if the server agreed to it or not.

The only way is through educated guessing in the data callbacks. And since the server was never required to agree to anything i see no problem here. You always needed error handling in case the BLKSIZE was not what you expected.

If you meant code inside libcurl, i did not encounter anything myself.

I just pushed commit 60c8629, which makes all TFTP test cases verify that the exact set of options is passed to the server so checking for a lack of those options is now also possible.

@bagder Where are we with the feature window? I can't find a notice it will be closed. I have some time tomorrow and I'd like to land this, it just needs a test. Also I'd like to get in CURLINFO_TLS_SSL_PTR, I relent on my bikeshedding over the name.

ouch, I completely forgot to post a note about it. But as you probably felt, we're beyond that now for 7.47.0 - release date is set for Jan 27th. (I'll send an email now)

@mkoenig75 Landed in 9dc3eae and 186546f. Thanks and sorry for the long delay.