Here's a strange one, and I'm not sure how to go about fixing it:

I have an application which uses libcurl to fetch html pages and then
links & images. One site I was testing with caused libcurl to error on
an image link, even though the page appears fine in IE and netscape.

The cause is a badly formed '302 Moved Temporarily' response from the
server (an ad server with rotating banners, it seems).

Here's the command line reproduction:

$ curl
http://ads.tucows.com/image.ng/pageid=001-005-000-000-000-001-029-016-005
curl: (18) transfer closed with 10 bytes remaining to read

(I get a '500' status from libcurl, and the same status text)

Looking at the request in detail, its easy to see the problem:

-----------------------
$ curl -I
http://ads.tucows.com/image.ng/pageid=001-005-000-000-000-001-029-016-005

HTTP/1.0 302 Moved Temporarily
Connection: close
Server: Netscape-Enterprise/4.0
Date: Fri, 31 Aug 2001 02:55:47 GMT
Set-cookie: NGUserID=d8282082-18189-999226547-19; expires=Wednesday,
30-Dec-2037 16:00:00 GMT; path=/
Cache-control: no-cache
Pragma: max-age=0
Content-Length: 10
Location: http://www.tucows.com/tucows/ads/Rackspace/468x60/1011.gif

------------------------

The server says 'content-length: 10' and doesn't provide any content.
Its the servers fault, its broken. Unlike 304 (redirect), which MUST NOT
have a body, a 302 is described by rfc2616 as allowing a body, generally
containing a user readable redirection link, so a content-length header
is legal, and can't just be ignored.

My problem is that standard browsers are not phased by this illegal
server response, and just go ahead and follow the redirect - so the
libcurl based app appears to be 'at fault' when the image load fails,
even though both server and standard browsers are 'in the wrong'.
Because the server says 'connection: close', I guess there's little risk
in this, as the client can't get out of sync with the server like it
would with a keep-alive request.

I could probably fudge my app to look for 302 status and ignore the
failure (I think libcurl lets me see the real status, despite the
failure, didn't look yet), but is it an issue that libcurl should/could
address, for maximum compatibility with 'standard' (broken) http
clients?

Suggestions please...
Cris
Received on 2001-08-31