> Armel Asselin wrote:
>> >The priority setting P could be used in addition to L or instead of L.
>> >If
>> >libcurl has an important transfer it submits it with a high priority and
>> >libcurl will immediately (or after a period L) open a new connection if
>> >no
>> >connections are completely free. If a low-priority transfer is
>> >submitted,
>> >libcurl would never open a new connection, but wait until all
>> >higher-priority
>> >requests are complete.
>> if there is a priority stuff, one mandatory thing: order should be
>> respected for equal priorities... not easy but for example when using
>> WebDav MKCOL... you do not want the dependent HTTP PUTs to happen before
>> it
>> occurred so they must be pipe-lined to the same connection or must wait
>> for
>> the response.
>
> Are you sure it is safe if they're pipelined to the same connection?
>
> I can easily imagine a server design which will process the requests
> in parallel, even though they come on the same connection, and only
> serialise when it comes to outputting the responses.
>
> In particular, I can imagine a proxy (HTTP proxy, or HTTP to CGI,
> etc.) doing exactly that without knowing anything about the types of
> requests.
>
> That kind of server wouldn't work with pipelining PUT after MKCOL when
> they are dependent. You'd have to wait for the result from MKCOL
> before sending the PUT.
unfortunately you're probably right, the fact is just that even if using
pipe-lining libcurl should let us do this kind of synchro, but it must be
pretty built-in, one just have to wait for the MKCOL request/response to be
done before sending dependent stuff.

Armel
Received on 2006-06-23