On Thu, Jun 2, 2011 at 15:57, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On Wed, May 25, 2011 at 09:28, Justin Erenkrantz <justin_at_erenkrantz.com> wrote:
>> On Tue, May 24, 2011 at 6:32 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>>> It's really hard reproduce problem, because it's related to timing of
>>> sending and receiving requests. From the code my feeling that issue is
>>> still exists, just in more complicated scenario with more requests but
>>> I didn't find reproduction script.
>>
>> Can you give me an idea why you think the issue still exists? We'd be
>> adding the new priority requests after all of the previously-queued
>> (but unwritten) priority requests...so, unless I did a silly think-o,
>> I don't see why it would if the situation matches what was described
>> in the issue. -- justin
>>
> May be it's different issue, but in case if server doesn't require
> authentication for all requests and allow anonymous access for some
> requests:
> C: GET /restricted/
> C: GET /public/
> S: 401 /restricted/
> S: 200 /public/ (client gets notification that second request is completed)
> C: GET /restricted
> S: 200 /restricted (clients gets notification that first request is completed)
I don't see how re-ordering GET requests is a problem. This will
naturally occur since ra_serf uses multiple connections. The server is
free to respond to each connection however it wishes. ... and if it
does so... I'm not sure what actual problem that causes.
Cheers,
-g
Received on 2011-06-02 22:17:42 CEST