Re: [Last-Call] draft-ietf-lamps-rfc5273bis-08 telechat Httpdir review

Am 16.10.2025 um 19:53 schrieb Sean Turner:
> Just bumping this one back up.
> 
>> On Sep 25, 2025, at 11:03, Sean Turner <sean@sn3rd.com> wrote:
>>
>>
>>
>>> On Sep 18, 2025, at 07:32, Julian Reschke 
>>> <julian.reschke=40gmx.de@dmarc.ietf.org> wrote:
>>>
>>>>>
>>>>> "Clients and servers are expected to follow the other rules and 
>>>>> restrictions in
>>>>> [HTTP]. Note that some of those rules are for HTTP methods other 
>>>>> than POST;
>>>>> clearly, only the rules that apply to POST are relevant for this 
>>>>> specification."
>>>>>
>>>>> Hm, not really. For instance, servers have to support GET and HEAD 
>>>>> (that's a
>>>>> basic HTTP requirement), clients need to properly process 1xx 
>>>>> responses. Is
>>>>> support for chunked transfer encoding required? (see RFC 9112, 
>>>>> Section 6.1)?
>>>>> Are requests using chunked transfer encoding forbidden?
>>>> We hadn’t discussed chunked transfer encoding. We are thinking it 
>>>> shouldn’t be used to ensure interoperability, but probably need to 
>>>> ask the WG.
>>>
>>> Please do :-)
>>
>> Julian,
>>
>> Hi! On this point, my initial thoughts were let’s just prohibit it. 
>>  But, the question I got in return was whether can we get away with 
>> saying nothing (it says nothing now)?  This is motivated by some day 
>> job experience where a CMP server was deployed into a public cloud, 
>> and the requests got “molested" by many layers of HTTP Proxies before 
>> it got anywhere near infrastructure that they controlled. Some of the 
>> proxies were configured to de-chunk chunked requests. So in practice, 
>> guaranteeing that the web service rejects chunked messages was a bit 
>> of a circus show.

https://www.rfc-editor.org/rfc/rfc9112.html#section-7.1-4

 > A recipient MUST be able to parse and decode the chunked transfer coding.

So once you try to profile HTTP (here 1.1), you'll get into trouble when 
parties are involved which assume that they're talking with compliant 
components.

It's possible to do these things when you can control client, servers, 
and intermediaries. But in that case, the protocol is not HTTP - it just 
looks as if it was.

Best regards, Julian

Received on Thursday, 16 October 2025 23:06:52 UTC