Hi,

> The protocol you described is not HTTP because HTTP has precise
> message boundary rules.

I could not agree more. It is just http-ish enough to make me want to
use libCurl instead of handcoding to it.

> Since the protocol being used is not HTTP, I would recommand against
> such a change in curl, especially when the other solution looks easy:

Sorry, I did not want to suggest a change to libCurl. I was thinking of
checking for the end of the content - as determined from that content
itself - inside of my write-function. In fact I tried that and it goes
like this:

If the write-function detects a complete transfer by looking at what was
transferred it writes the data to the stream and then returns -1
indicating a failure.

This failure prompts libCurl to stop transferring. It is then passed
on to the part of my code that called perform(). In my case as an
Exception because I am using curlPP as a wrapper.

Catch that exception, check for the exact error code (Write failure).
If that is the case check wether the response was flagged as complete
from the write-function. If so, be happy and process it. If not
re-raise the error as it appears to be genuine.

Works and is almost acceptable :-).

>> Should I take away the keep-alive from the last request?

Tried that but the server could not care less. It does not close the
connection and thus nothing is gained.

I upgraded my assessment from brain damaged to braindead after that
discovery.

Ciao, MM
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2009-10-08