RTT wrote:
> 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.
IMO a global option is not very useful. You may not always want to
accept range requests.
> 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?
Ranges are typically used to download large static/file content in
parallel with multiple connections, that's no problem since SendDocument
method uses a file stream. The SendStream method however is typically
used for dynamic content and with a TMemoryStream, if so, entire memory is
allocated regardless of the range size requested. Also if content
changes with each request accepting ranges may corrupt data when a client
assembles the data chunks locally. So there must be an option to allow
ranges on a per request basis. A new method would provide such an option.
> 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?
Dunno, AnswerString doesn't accept/handle ranges.
--
Arno Garrels
--
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
