httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: Apache 1.1b4... where is it?
Date Sun, 16 Jun 1996 19:46:37 GMT
Roy T. Fielding wrote:
> 
> >Speaking of HTTP/1.1, I find the WG's attitude to clock skew somewhat baffling.
> >The question is completely bypassed for caches (unrealistically in my view) and
> >yet is used as a defence for the strategy for evaluating the strength of
> >validators.
> 
> Clock skew is not "bypassed" for caches -- it is worked-around by way of
> the Age header field and age-estimation algorithms.  There is no other way
> to handle clock skew.  Whether or not that is clear from the spec is
> unknown to me, since I have never been able to read through the new
> caching section without screaming in disgust and skipping large blocks
> of redundantly broken pseudo-English.
> 
> > Comments to this effect have been ignored. So, I, for one, intend to correct
> > the spec when it comes to date-stamping cached copies.
> 
> You made one comment, and it was answered by Jeff, to which you replied
> with another comment.  You did not provide an example wherein
> the spec is wrong -- in fact, you didn't even suggest a workable
> "solution" for the problem, and the problem wasn't adequately identified
> either (or at least not to an extent that anyone else could see it).
> We (the editors) talked about it during our teleconference and did
> not see any problem that needed solving.

I made more than one comment. Some were answered, some were not. The one in
question was my comment on 13.2.3, which (as far as I know) was never answered.

Specifically, I was complaining about the suggestion that caches should (not
SHOULD) use NTP to synchronize time. Given that most caches live on
workstations this is not likely to happen in practice, and besides seems to me
to be beyond the scope of the spec (unless you expect servers/clients to
actually implement NTP internally).

I've reread the section (in the latest version I have - Rev84) and I see that
if the Age version of the calculation is used, clock skew is not a problem, or,
rather, is allowed for.

I doubt the value of the alternate method for calculating age without a
correction for clock skew, which can be estimated by
date_value-(response_time+request_time)/2 (or a more conservative formulation,
if preferred).

> 
> The WG does not have an attitude -- the editors do.  Our attitude is
> that we are sick of editing the specification and see no advantage
> in further delaying the process.  What little time we did have for
> making changes was spent on fixing the parts which were drastically
> wrong, rather than just implementation details.  I know of several
> minor problems that are still present in draft 05, but none that will
> affect compliance, and therefore none that I am willing to
> delay the RFC just to see fixed.
> 
> To make a change to the spec, you must provide the exact wording for
> the change, along with a convincing argument that it is needed if it
> isn't obvious from the diff.  Otherwise, the comment will be ignored,
> as was clearly stated by Larry and Jim for the past two drafts.
> [Many of the changes suggested by the editors were made after two weeks of
> face-to-face meetings and six hours of teleconferencing over the past
> month, which is why there seems to be so little discussion about them
> on the WG mailing list.]
> 
> > I haven't gone so far as to complain to the IESG but I'm considering it.
> 
> The IESG will tell you to talk to the Chair, and Larry will tell you to
> post the problem and solution to the WG.  Waiting until the last minute
> will just make it harder to change the spec.  However, I couldn't see
> anything wrong with the caching part regarding clock skew other than
> the goofy wording about NTP (which is no worse than the rest of the
> caching section), so I doubt that a change is in order.

Given that the Age version of the calculation works for HTTP/1.1 (which I
hadn't appreciated first time round), I'm not worried about it _too_ much,
though I'll probably attempt to put clock skew compensation into the Apache
proxy one day, for the other method.

If you think its worth my while (that is, will get included) documenting it for
HTTP/1.1, I guess I'll do it.

> 
> HTTP/1.1 may not be through the IESG yet, but it is "done" in terms
> of my input.  I have moved on to other things (like my own source code
> that hasn't been updated in two years, like reinstalling everyting
> associated with GNU so that I can get a working CVS so that I can
> actually contribute code again for Apache, like actually starting the
> libwww-Ada95 project that I've been "working on" for the past four
> months, like writing research papers that have some relevance to my
> as-yet-unknown dissertation topic, like making it at least a somewhat-known
> dissertation topic, like maybe getting to see The Rock before the next
> Apache release, like coming up with a hobby that doesn't involve sitting
> on my ass in front of a screen, like getting a real life, like ...). 
> 
> Yeah, I'll probably only get to the first three within the foreseeable future,
> but at least I won't have to defend my every action to the bloody
> peanut gallery.

Sorry.

Ben.

BTW, if you want a non-ass-sitting hobby, perhaps you _shouldn't_ get CVS
working ;-)

> 
> ......Roy

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.

Mime
View raw message