On 11/4/2015 8:11 AM, Michael König wrote:
> Hi everyone!
>
>> Ray Satiro via curl-library <curl-library_at_cool.haxx.se> hat am 24. August 2015
>> um 06:52 geschrieben:
>>
>>
>> On 8/21/2015 10:16 AM, Michael König wrote:
>>>> Daniel Stenberg <daniel_at_haxx.se> hat am 20. August 2015 um 23:20
>>>> geschrieben:
>>>>
>>>>
>>>> On Wed, 19 Aug 2015, Michael König wrote:
>>>>
>>>> If you think you can get something like that written into the documentation
>>>> for this new option as well, my objections are squashed and I'll even help
>>>> writing up a test case for it. =)
>>> Deal!
>>> Keep in mind, that was quite likely the first time i ever modified/created
>>> manpages. I used a lot of copy&paste.
>> I think this would be a good option to expose in the command line tool
>> curl so I made some changes for that [1]. I also modified your terms
>> some. You short description of the option is 'Prevents TFTP options to
>> be send with RRQs/WRQs' which is complex for a short description. I
>> changed it to 'Do not send TFTP options requests' and also matched that
>> short description in several places. In the detail of the option it now
>> includes those facts in the description:
>>
>> "Set \fIonoff\fP to 1L to exclude all TFTP options defined in RFC2347,
>> RFC2348 and RFC2349 from read and write requests (RRQs/WRQs)."
>>
>> Also I removed your assertion that not sending the TFTP options will
>> make us conform to RFC1350. I may have overstepped on that, but I don't
>> know that it's a correct assertion (didn't read the RFC).
>>
>> 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.
>>
>>
>> [1]:
>> https://github.com/jay/curl/compare/master...jay:tftp_no_options?expand=1
>>
> Rays work did not make it into the last release. Was it just forgotten or are
> there open issues with this? I am still very interested in this option.
>
> If there are open issues, is there any way i can help resolve them?

Hi Michael, the issue is being tracked at
https://github.com/bagder/curl/issues/481 and its current state is
described there. Basically it needs a test case. The feature window
closes tonight so it might not make it in again unfortunately. The test
case would be an xml file that uses the curl tool to send a request to
the test tftp server with --tftp-no-options. In this way we can test the
curl tool and libcurl at the same time. The time consuming part looks to
be finding a way for the tftp server to signal it did not receive
options and then catching that in the test so we know whether or not the
test passed. The deadline is Wed midnight and I assume Swedish time
which is in a few hours. I can take a look at it this evening unless you
or Daniel beats me to it but that would be after the deadline because
I'm on eastern time (6 hours earlier here).
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-11-04