On Tue, Sep 22, 2009 at 10:15:17PM -0400, Seth Vidal wrote:
> arguably you could be handed an endless header and obliterate all memory.
> I put a configurable max header size (default to 2mb) in place and work
> from there.

Is this actually a case that we can hit if the client hasn't installed a
HEADERFUNCTION? I'm a bit surprised that curl would hold onto all of
the headers, instead of just extracting the ones that it cares about.

>> I used the multi interface, so my approach may not map exactly to what
>> you're doing. However, I created an object that contained a bunch of
>> information about the transfer. This object also contained the
>> progress_callback(), so progress_callback(self, ...) always referred to
>> the transfer that was in progress. I made sure that the easy handle had
>> a reference to this object. When you're in your error loop, processing
>> the easy handles that have failed, look at the object that you assigned
>> to the handle. If the reason for the transfer's abort was saved in that
>> object, then all you would have to do is check the code (transfer too
>> large, aborted by user, whatever) and then raise the error that you
>> actually wanted to raise when you aborted the callback.
>>
>
> That does make sense and it is what I ended up doing - but it felt a
> little hacky.

I have to admit I thought the same thing the first time I wrote code
this way. However, having the callback attached to an object that knows
something about its own state seemed like a reasonable approach in an OO
language.

> I also wish there was a nice way to go from errorcode->string in the
> python library.

There's easy.errstr(), but it only returns the error string from the
current handle. There's no curl_easy_strerror() equivalent in pycurl,
AFAICT.

-j

_______________________________________________
http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-and-python
Received on 2009-09-23