W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Re: #282: Recommend minimum sizes for protocol elements

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Sun, 26 Jun 2011 08:19:30 +0000
To: Mark Nottingham <mnot@mnot.net>
cc: httpbis Group <ietf-http-wg@w3.org>
Message-ID: <50022.1309076370@critter.freebsd.dk>
In message <A2439359-80C0-466D-9E1A-7A9316F9FBD0@mnot.net>, Mark Nottingham wri

>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 ?

	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.

>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".

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Sunday, 26 June 2011 08:19:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:52 UTC