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

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