Re: If-Modified-Since and forged dated

> I think, that adding some redundancy to if-modified-since feature will
> help us overcome any unspecified data-integrity troubles.

I do agree that adding redundancy to 'if-modified-since' would help
overcome data-integrity troubles, but those data-integrity troubles
are often of a nature that a 'length' hint isn't useful. I don't think
we should close our eyes and say 'data-integrity troubles' are
unspecified; we have ample experience with a wide variety of them, and
we should pick a solution that actually solves problems that don't
have other solutions.

> CERN HTTPD/3.0 has a configuration parameter OutputTimeout, its default value 
> 20 mins. While sending the response to the client, this timeout is in effect,
> and after the timeout elapsed, prematurely disconnects the connection.
> If the client isn't enough picky, (and lynx 2.4.2, Netscape 1.1N and the
> CERN HTTPD/3.0 itself acting as proxy aren't) we will have truncated documents
> as the result, no complains, error messages at all.

> If we had the proposed redundancy, we will able to detect that something went
> wrong, and had a try to recover the problem some way.
> Not having the redundancy, the recovery process will start only after some
> human intervention, when the problem detected.

> If this unnice situation happens with my proxy cache, I can run my perl
> script, which checks the whole cache for cached documents having
> Content-Length header, and removes truncated files. It's a workaround,
> but it's really an overkill, scanning a big cache for a few or no files at all.

This particular problem can be addressed by modifying the behavior of
caching programs not to cache data where the reliability of the
transmission is suspect. Clearly anything with less data than was
specified in the 'content-length' header is suspect, and shouldn't
have been put in the cache in the first place.

If you're going to mandate protocol changes in order to fix problems
and those protocol changes require caching programs to change their
behavior based on those protocol changes, why not just mandate that
the cache programs just fix buggy behavior?

Probably we should also ask that that in any transaction that doesn't
have a way of confirming the integrity of the transaction (e.g., HTTP
0.9 implementation or no content-length, content-md5,
content-transfer-encoding: packet) the sender should have a default
timeout of N seconds (at which time it should close the connection);
the recipient should have a default timeout of K seconds (at which
time it should assume that the transmission was prematurely terminated
and the document not cached or saved) and K << N. If N is 20 minutes,
maybe K should be 5 minutes.

I'm not opposed to having a content-MD5 and even a 'if-different-MD5'
request, if you want to deal with end-to-end data integrity issues.

Received on Wednesday, 16 August 1995 18:56:08 UTC