On 05/11/2013 01:15 AM, Richard Moore wrote:
> On 10 May 2013 11:32, wrote:
>>> QHostInfo has a short-lived cache, so it should work.
>>
>> Yes, but relying on implementation details isn't a good idea.
>>
>> I thought the proposed feature could be more generally useful, for example
>> using test
On 05/09/2013 10:59 PM, Thiago Macieira wrote:
> On quinta-feira, 9 de maio de 2013 22.43.06, Justin Karneges wrote:
>>> Good. Then you can use QHostInfo, since it will use only 5 threads.
>>
>> I should have been more clear. I may not want 100 threads, but I also
>
On 05/09/2013 10:35 PM, Thiago Macieira wrote:
> On quinta-feira, 9 de maio de 2013 22.09.06, Justin Karneges wrote:
>> By that I meant I want the underlying implementation to be event-driven,
>> not simply the interface (QHostInfo is thread-backed). This is for a
>> server a
On 05/09/2013 08:57 PM, Thiago Macieira wrote:
> On quinta-feira, 9 de maio de 2013 19.36.45, Justin Karneges wrote:
>> Also, I'm not using QHostInfo, but rather my own resolver JDNS, because
>> I want the resolutions to be event-driven.
>
> What do you mean by that?
On 05/09/2013 06:44 PM, Thiago Macieira wrote:
> On quinta-feira, 9 de maio de 2013 18.00.36, Justin Karneges wrote:
>>> I understand the feature would be useful in certain conditions, but I'm
>>> not
>>> sure yours is one of them. You ca
On 05/09/2013 04:54 PM, Thiago Macieira wrote:
> On quinta-feira, 9 de maio de 2013 16.44.10, Justin Karneges wrote:
>> Hi people,
>>
>> I discussed this feature with Shane and went ahead and made a patch.
>>
>> The idea is to be able to explicitly specify a TC
Hi people,
I discussed this feature with Shane and went ahead and made a patch.
The idea is to be able to explicitly specify a TCP host/port target for
an HTTP request, while leaving everything else alone. The HTTP Host
header, TLS certificate validation, and TLS server name indication would
