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 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 live servers that are configured exactly as the live
Subject: [Development] QNetworkRequest: allow overriding connect host
>
> Hi people,
>
> I discussed this feature with Shane and went ahead and made a patch.
>
Hi Justin,
I meant to discuss the feature API on the mailing list.
If your patch is ready for review, you should submit it to the gerrit
> 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 live servers that are configured exactly as the live server so they
have a DNS address not
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
>> don't want queries being blocke
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
> don't want queries being blocked by others.
Our experience is that DNS servers o
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 application that needs t
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 application that needs to make outbound HTTP requests in bulk as
> fast 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?
By that I meant I want the und
On quinta-feira, 9 de maio de 2013 19.36.45, Justin Karneges wrote:
> > QHostInfo has a short-lived cache, so it should work.
>
> Mmmm, if QHostInfo's cache behaves like any other DNS cache then I don't
> see this making a difference. Unless every cache hit causes the cache
> time to extend, there
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 can probably just easily override the
>>> QNetworkAccessManager
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 can probably just easily override the
> > QNetworkAccessManager class and do the IP address verification. If it
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 TCP host/port target for
>> an HTTP requ
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 TCP host/port target for
> an HTTP request, while leaving everything else alone. The HTTP Ho
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
15 matches
Mail list logo
