On Mon, 3 Sep 2001, Cris Bailiff wrote:

> > I wonder if we could come up with some kind of system to turn optional
> > "problems" or "violations" into mere informationals...? Like
> > curl_allow_protocol_abuse_if_you_can_continue_anyway() ?
>
> A nice idea - I guess the 'error' function could fake up a whole 500
> reply depending on the switch, though its tricky to call all the correct
> file and callback hooks after that. In fact, it might be easier to have
> it as a curl feature, rather than a library feature - it seemed easy
> enough to do this for myself in my app, and get the specific format that
> I wanted.

Well, there's a big difference: when libcurl encounters an error, it stops
processing a lot of things. Things like Location: folllowing will be
cancelled when the library finds an error, so therefore there might be a big
difference between putting the error in the client side or on the library
side.

> Well, of course, I'm solved now, but perhaps its a curl feature rather
> than a libcurl feature?

Work-arounds are good. It gives us some more time to ponder on a solution
that fits us. I can't say I've come to think of any good ways to smoothen
this out.

If we were to add an option to libcurl, what would the option do? Just make
it ignore size problems such as these, or would it imply greater
understanding for other protocol abuses as well? Or would it only ignore size
problems when HTTP transfers return 3XX-codes or only specificly on
302-codes? Questions and questions... :-)

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/