Thanks for the modification, I've now applied the patch to my
workspace and given it some testing. There's one thing I don't quite
understand. Before the patch, Wget's timestamping was based on
analyzing the Last-Modified header, working like this:
1. Send a HEAD request and get the response.
2.1. If the response contains Last-Modified and it indicates that the
remote file is older, tell the user that there is no need to get
the file.
2.2. Otherwise, send a new GET request and download the file.
The problem is that we're sending *two* requests for each new file --
a HEAD request to get the last modification time, and a GET request to
actually download the file. If-Modified-Since gives us a way to get
rid of the HEAD request, and of the need to parse Last-Modified. I
assumed that, after your patch is installed, that Wget would do this:
1. Send a GET request with the If-Modified-Since header.
2.1. If the response is "304 Not Modified", tell the user that there
is no need to get the file.
2.2. If the response is something other than 304, start downloading
the file immediately, without firing up a new request.
But your patch does not seem to do that. It sort of implements both
strategies:
1. Send a HEAD request and get the response.
2.1. If the response contains the Last-Modified header and it
indicates that the remote file is old, tell the user that there
is no need to get the file.
2.2. Otherwise, send a new GET request with `If-Modified-Since'.
2.2.1. If the response is "304 Not Modified", tell the user that there
is no need to get the file.
2.2.2. If the response is something other than 304, start downloading
the file immediately, without firing up a new request.
Did you do it this way intentionally? I mean, it doesn't *break*
anything, but it causes HTTP timestamping to be implemented in two
different ways and it doesn't implement the improvement expected from
using If-Modified-Since.
Do you agree that it would be a good idea to only use
If-Modified-Since?
