On 11/4/2015 8:11 AM, Michael König wrote:
Hi everyone!
Ray Satiro via curl-library <[email protected]> hat am 24. August 2015
um 06:52 geschrieben:
On 8/21/2015 10:16 AM, Michael König wrote:
Daniel Stenberg <[email protected]> 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
