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
