Re: #282: Recommend minimum sizes for protocol elements

On 26/06/2011, at 6:19 PM, Poul-Henning Kamp wrote:

> In message <A2439359-80C0-466D-9E1A-7A9316F9FBD0@mnot.net>, Mark Nottingham wri
> tes:
> 
>> 1.4.x Delta Seconds
>> 
>> The delta-seconds rule specifies a non-negative integer, representing =
>> time in seconds.
> 
> Some high volume sites cache content for only a couple of seconds,
> but derive 20-30% cache hit ratios from it.  For these sites the
> 1 second granularity of age related values are a serious limitation
> on caching policy.
> 
> Does anybody know of anything that would break if we allowed real
> numbers for these fields ?
> 
> ie:
> 	delta-seconds = 1*DIGIT [ '.' *DIGIT]
> 
> Specifying truncation rather than rounding for implementations that
> do not support real numbers, would ensure compliance for existing
> implementations.  The 2^31 should remain unaltered.

I've found such low TTLs useful as well, but only in controlled deployments (i.e., reverse proxies). For forward proxies and browser caches, you can't assume clock sync that tight (IME clock sync is a problem even in reverse proxies).

Nothing stopping you from specifying a CC extension with higher precision, of course, but realise that Date only has one second resolution.


>> For other situations, add section to p1 Security Considerations:
> 
> Do we need to caution against dropping headers selectively due
> to size ?
> 
> I know of at least one filtering device which can be circumvented
> by making a particular header longer than a certain length.  This
> causes the device to drop just this one header, which in turn
> bypasses filter features.  (The vendor has been notified, but
> emits few if any clue-o-trons)
> 
> I'm not quite sure how to express this, something like "don't drop
> headers unless you know what they mean".

I *think* Roy intends to expand upon this in "Use of HTTP for proxy communication" in p1.

Cheers,


--
Mark Nottingham   http://www.mnot.net/

Received on Monday, 27 June 2011 08:56:24 UTC