On Tue, 16 Oct 2001, Stephen Welker wrote:

(PLEASE keep curl mails on the list, I'm working up a nasty backlog of curl
mails right now and keeping them on the list enables fellow hackers to join
in and take part in solving problems and discussing ideas...)

> --fail option --> to prevent server errors producing documents that can
> not be processed at my end.

This is the key to the problem. I did make this return error if the error
code is 300 or higher (unless follow location is set, when 400 is required to
get an error signalled), but considering the standard and recent occurences
like yours, I am rethinking this decision.

Can anyone see any reason why 300-399 should return error when --fail is
used? If not, that exception will be removed and this whole issue will be
solved the most elegant way (= removing code).

> Now the interesting thing is that the config above does work if the cache
> reports a "200" status - but some how the document is not transfered as
> it has not been modified since the last time it was downloaded.

I can explain why that happens. When you set a time condition, curl will
include headers to let the server do the comparison which may result in a 304
code being returned. Or else, a 200 is returned and a full response-body.
Curl then doublechecks the time condition by itself, and if it finds out that
we didn't want this document, we "bail out" from the transfer and returns OK.

-- 
      Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol