Hi,

I am writing a libcurl/curlPP-based program to talk to a handmade
webserver that is at least severely brain-damaged.

The protocol requires two GETs to URLs for a login and retrieval of a
session-ID and finally a GET to fetch the payload the program is
actually interested in. These three GETs have to be made in the context
of the same TCP/IP-connection.

That in conjunction with providing a session-ID constitutes half of the
brain-damage. The second half lies in the fact that the payload is
delivered without a Content-Length:-header. So the code does not know
when it's done.

The developers of the server are using a client with equally handmade
client-side http-code that parses the content to find out where it ends.
As that content is a mashup of almost-XML and CSV a painful task that
I'd like to avoid in my libCurl-based code.

My current pattern is using the Easy-Interface and dumping the content
to a std::stringstream as it comes in via a curl write-function. So I
have a nice configure-request, make-request and then process-results
sequence in my code. Pretty.

When I run this on the given case the final reaction is:

> no chunk, no close, no size. Assume close to signal end

Then it waits until some timeout and returns the content it has seen.
That is what I expected.

Now what best to do about it?

If I were to parse the content in the write-function to find the end,
how could I signal that to libCurl? I found from the docs that I can
return anything smaller than the size that was passed in. but that would
show up as an error in my code, which is isn't. So I would have to
somehow flag that as "no, not really, complete content". Possible but
not very elegant.

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

Thanks for reading this! I can show code if necessary, but I suspect
that is not going to be of much help.

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