Zitat von Micah Cowan <[EMAIL PROTECTED]>:
> > Zitat von Jochen Roderburg <[EMAIL PROTECTED]>:
> >
> >> So it looks now to me, that the new error (local timestamp not set to
> remote)
> >> only occurs in the cases when no HEAD is used.
> >
> > This (new) piece of code in http.c (line 2666 ff.) looks very suspicious to
> me,
> > especially the "time_came_from_head" bit:
> >
> > /* Reparse time header, in case it's changed. */
> > if (time_came_from_head
> > && hstat.remote_time && hstat.remote_time[0])
> > {
> > newtmr = http_atotm (hstat.remote_time);
> > if (newtmr != -1)
> > tmr = newtmr;
> > }
>
> The intent behind this code is to ensure that we parse the Last-Modified
> date again, even if we already parsed Last-Modified, if the last one we
> parsed came from the HEAD.
Hmm, yes, but that is not what it does ;-)
I mean, it does not parse the date again "even if" it was already parsed, but
"only if" it was already parsed. So especially it does *not* parse it if there
had been no HEAD at all before.
And the only other code I found which parses the remote date is in the part
which handles the logic around the timestamping option. In older versions this
was a conditional block starting with if (!got_head) ... , now it starts with
if (send_head_first && !got_head) ... Could this mean that this code is now
only executed when a HEAD response is examined ??
Anyway, I think everything is ok again when you just eliminate this
time_came_from_head logic completely. The above piece of code then just sets
the local timestamp to the last remote timestamp which was seen and does not
care from which HEAD or GET requests it actually came.
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10 Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED]
Germany
