Re: Andy Newton's Discuss on draft-ietf-httpbis-cache-groups-05: (with DISCUSS)

On 4/30/25 20:21, Mark Nottingham wrote:
> Hi Andy,
> 
>> On 1 May 2025, at 6:52 am, Andy Newton via Datatracker <noreply@ietf.org> wrote:
>>
>> Thanks for writing this document. It is very well written and easy to read.
>>
>> ### Your Fav Pop Star HERE
>>
>> I hate to be that guy, but...
>>
>> 187        Cache-Group-Invalidation: "eurovision-results", "kylie-minogue"
>>
>> TIL that Australia is a member of the EBU and therefore this is a logical
>> grouping, however does this document require the use of real people and
>> organizations to create an interoperable specification?
> 
> Require? No. However, realistic examples are more illustrative and useful to readers.

Looking at your conversation with Deb, I see you plan to change this example. Thanks.

> 
>> ### Maximum Length
>>
>> I see that minimum lengths are set:
>>
>> 205        Implementations MUST support at least 32 groups in a field value,
>> 206        with up to at least 32 characters in each member.  Note that generic
>> 207        limitations on HTTP field lengths may constrain the size of this
>> 208        field value in practice.
>>
>> However, no maximum field or string lengths are set. I see this in RFC 9651:
>>
>>     This specification defines minimums for the length or number of
>>     various structures supported by implementations. It does not specify
>>     maximum sizes in most cases, but authors should be aware that HTTP
>>     implementations do impose various limits on the size of individual
>>     fields, the total number of fields, and/or the size of the entire
>>     header or trailer section.
>>
>> Should this document set maximums? If not, is the expected behavior that the
>> headers are ignored?
> 
> Adding yet another maximum to those that are implementation-defined would make interop even more difficult -- especially since some would read that as "these sizes are supported" even though other maximums would interfere.
> 
> Current practice in HTTP is what we've done -- define a floor so that people can depend on a certain level of support, but leave the top end open so that we don't foreclose use cases that require large values. See eg Structured Fields, URL sizes.

Section 2.2 of RFC 9651 appears to say that limits can be placed here:

     When parsing fails, the entire field is ignored (see Section 4.2).
     Field definitions cannot override this because doing so would preclude
     handling by generic software; they can only add additional constraints
     (for example, on the numeric range of Integers and Decimals, the
     format of Strings and Tokens, the types allowed in a Dictionary's
     values, or the number of Items in a List).

If there are no maximums, there appears to be some undocumented point when these values become ignored. And if they are ignored, there isn't a mechanism to communicate that they are being ignored, correct? Is that not an interoperability concern?

-andy

Received on Thursday, 22 May 2025 07:10:06 UTC