Re: Binary HTTP [RFC 9292] header name behavior

> On Aug 18, 2025, at 12:31 PM, David Benjamin <davidben@chromium.org> wrote:
> 
> Is it actually possible for the 18.0-18.3 clients to actually emit non-lowercase field names in practice, or is it just that the BHTTP layer didn't enforce it?

It should just be that it wasn’t enforced, and not enforced on decoding.

> I.e. it's unclear to me how to interpret "all of the applications that run with it use lower-case field names". Is this some public API that arbitrary applications might trigger and exercise, or is there a closed set of OS component senders that (we believe) all send lowercase? If the latter, perhaps we can still be strict about it.

I agree that this is something the ecosystem can be strict on.

Tommy

> 
> 
> On Mon, Aug 18, 2025 at 12:30 PM David Schinazi <dschinazi.ietf@gmail.com <mailto:dschinazi.ietf@gmail.com>> wrote:
>> Doesn't that mean that gateways are stuck dealing with 18.0-18.3 clients forever? iOS devices have a good update rate but it's not 100%.
>> David
>> 
>> On Sat, Aug 16, 2025 at 10:51 AM Tommy Pauly <tpauly@apple.com <mailto:tpauly@apple.com>> wrote:
>>> Actually — an update on this for our client behavior! While the original implementation didn’t enforce lowercase, the iOS and macOS client does enforce lowercasing for both sending and receiving as of the iOS 18.4 timeframe. So I think there isn’t any issue (from our perspective) of saying everyone should be lowercase from here on out.
>>> 
>>> Thanks Guoye for reminding me of this update!
>>> 
>>> Tommy
>>> 
>>>> On Aug 15, 2025, at 4:49 PM, David Schinazi <dschinazi.ietf@gmail.com <mailto:dschinazi.ietf@gmail.com>> wrote:
>>>> 
>>>> Thanks Tommy.
>>>> 
>>>> Given that we have a widely deployed implementation that's not forcing a downcase, I think we might be stuck in the "tolerate non-compliance" equilibrium [1]. I'd suggest we write an errata saying that BHTTP encoders MUST downcase and BHTTP decoders MUST downcase to tolerate implementations from before the errata.
>>>> 
>>>> David
>>>> 
>>>> [1] https://www.rfc-editor.org/rfc/rfc9413#section-4.2
>>>> 
>>>> On Fri, Aug 15, 2025 at 4:42 PM Tommy Pauly <tpauly@apple.com <mailto:tpauly@apple.com>> wrote:
>>>>> The Binary HTTP implementation on iOS/macOS clients don’t force downcase field names currently, although all of the applications that run with it use lower-case field names, as far as I’m aware.
>>>>> 
>>>>> I’d be OK with downcasing going forward if that was the consensus of the group.
>>>>> 
>>>>> Tommy
>>>>> 
>>>>>> On Aug 12, 2025, at 4:54 PM, David Schinazi <dschinazi.ietf@gmail.com <mailto:dschinazi.ietf@gmail.com>> wrote:
>>>>>> 
>>>>>> I guess it comes down to what deployed implementations are doing in production. Google's implementation currently downcases on both encode and decode. If everyone does it on encode, we'd be happy to shift to rejecting on decode to be more in line with RFC 9413.
>>>>>> 
>>>>>> David
>>>>>> 
>>>>>> On Tue, Aug 12, 2025 at 3:22 PM Martin Thomson <mt@lowentropy.net <mailto:mt@lowentropy.net>> wrote:
>>>>>>> On Wed, Aug 13, 2025, at 06:25, Ricky Perez wrote:
>>>>>>> > Thank you for the context Martin! So just to clarify, should downcasing 
>>>>>>> > happen at the encoding path, at the decoding path, or at both paths?
>>>>>>> 
>>>>>>> Encoding.  The decoder would validate that the name was lowercase and reject.
>>>>>>> 
>>>>>>> > I'm happy to assist with filing the erratum, though let me know if you 
>>>>>>> > prefer I hold that off in favor of following some other process.
>>>>>>> 
>>>>>>> I'm going to wait for others to weigh in.  I don't entirely trust my instincts on this one.
>>>>>>> 
>>>>> 
>>>