Bugs item #2565128, was opened at 2009-02-04 20:51
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2565128&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: http
Group: wrong behaviour
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jocelyn (jocelynj)
Assigned to: Daniel Stenberg (bagder)
Summary: "not new enough" file when using CURL_TIMECOND_IFMODSINCE

Initial Comment:
Hi,

I'm using libcurl 7.18.2-8 in a C program, and I get the message "The requested document is not new enough" even if the server sends a file with response 200 OK. The problem I have with this behaviour is that the program depends on the HTTP response code to know if there was a more recent file or not on the server, and expects to receive a file when getting 200 OK. But in this case, curl doesn't modify the http headers, and makes a 0-byte file.

This behaviour happens if the server doesn't have a correct time, and is in the past. If the client sends a request with an If-Modified-Since header with a future date for the server, then the server can send a 200 OK response. I'm joining a file to show one transfer like this.

In my opinion, curl shouldn't check the file time in addition to the check done by the server, except if there is a good reason. I have checked curl code, and it seems that if there is a 304 http response received, libcurl already behaves correctly, and there is an additional code to check the filetime returned by the server (line 498 of lib/transfer.c on revision 7.19.3)

Thanks !

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

Comment By: Daniel Stenberg (bagder)
Date: 2009-02-09 16:41

Message:
Thinking about this further, we have the exact same problem with FTP but
for that protocol there is no 304 or similar so in order to signal this
back to the app we need something new.

I'm now more thinking of a new info-variable to be readable after a
transfer that was done with a time-condition, as I think it isn't quite an
error so returning an error-code would be a bit weird methinks. It would
then presumably also get set when a 304 is returned on a time-conditional
request.

What do you think about that idea?

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

Comment By: Jocelyn (jocelynj)
Date: 2009-02-04 22:05

Message:
Well, there are two ways of seeing things:

 - we trust everything that the server sends, so libcurl doesn't have to
check the time, and only returns what the server sent (http response code
anf file if one was sent)

 - we don't trust the server, so libcurl do another check on time. In this
case, I think that libcurl shouldn't mislead the application in thinking
that the server sent a 0-byte file.

If I understand your point, you prefer the second possibility. In this
case, shouldn't libcurl sends http response code 304 instead of an error ?

If you prefer not sending CURLE_OK, that's fine - I suppose that the
application will still be able to understand what happened by looking at
the error code.

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

Comment By: Daniel Stenberg (bagder)
Date: 2009-02-04 21:44

Message:
I beg to differ.

The option you pass to libcurl is about requesting a document modified
since a specific date, and libcurl takes measures to only deliver the
document if newer (or older) than the specified time. Why would you like to
get the document that hasn't changed even though you explicitly asked you
didn't want it then?

What I think could be argued is how this is signaled to the application,
as just returning CURLE_OK doesn't feel quite right to me as that would
imply a normal transfer which with it isn't exactly...

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

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2565128&group_id=976
Received on 2009-02-09