On 04-02-2012 16:45, Arno Garrels wrote:
That's a question too, IMO accept/handle ranges should be optional and silently changing the default behaviour of an existing method is questionable, no?
I totally agree with that. The server should have an options property to specify this kind of functionality. If AcceptRanges is the in options, then send the Accept-Ranges with all the response headers, and process valid ranges request in all the related response methods, AnswerStream included. This schema grants backward compatibility, because AcceptRanges must be explicitly turned on. May break it if that option is considered in SendDocument method, but without this kind of changes code can't evolve. The SendDocument already handle ranges (without an option to disable it) and ranges specific variables are being initiated, and related request headers being parsed, so why not extend the functionality to the AnswerStream too? And if application should not handle ranges, server can skip the creation of the ranges handling objects and the parsing of the request header specific keys.
By the way, why is the commentary "{ Do not use AnswerString method because we don't want to use ranges }" in the AnswerXXX methods?
-- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
