Interesting read Warren, thanks for sharing. On Sun, Jul 6, 2025 at 7:57 PM Warren Parad <[email protected]> wrote:
> Sure, but Postel's Law is actually harmful. And the "volume of LLM code" > isn't the relevant metric, but rather "What the future of generated LLM > code will look like". That is what is being generated at the moment, I > don't find relevant either, but rather what will be generated in the > future, and the implications of that. So we should be thoughtful about the > impact of the spec we write rather than seek to have the spec match only > what was a past reality. So, I generally recommend disregarding "Postal's > Law" as a long term strategy. This draft I find to be quite insightful on > the topic: > https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-05.html > > On Sun, Jul 6, 2025 at 8:48 PM Dick Hardt <[email protected]> wrote: > >> To be clear, lowercase or all uppercase are all valid. Many resource >> servers parse the header with code like I shared. >> >> The volume of LLM generated code is going to grow exponentially -- I was >> using Claude's latest version to get this result. >> >> Postel's Law: "Be conservative in what you send, be liberal in what you >> accept." >> >> The sample code is strict in what it accepts unfortunately. >> >> >> On Sun, Jul 6, 2025 at 6:34 PM Warren Parad <[email protected]> wrote: >> >>> I think we should consider which pattern would more likely avoid >>> security-related issues in the future. >>> >>> I also would completely disregard all LLM generated code. It is an >>> interesting heuristic for "the model got that suggestion from somewhere >>> with high enough frequency", but arguably the simpler the spec, the easier >>> it will be to generate compliant code by future LLMs. And also this will >>> change as time goes on, as implementations are generated more successfully. >>> >>> We also know that most earth providers can't even follow the spec on it >>> is today, creating their own custom things. It seems like being strick here >>> in the spec is better than not. >>> >>> Just like HTTP2 has lowercase headers, I wound prefer bearer to also be >>> lowercase, but I appreciate the breaking change that would require. >>> >>> "Being as permissible as possible" is not actually a good thing. >>> >>> On Sun, Jul 6, 2025, 19:23 Dick Hardt <[email protected]> wrote: >>> >>>> Which code is badly written -- the one that has two spaces? or the one >>>> that only parses a single space? >>>> >>>> On Sun, Jul 6, 2025 at 6:07 PM Thomas Broyer <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Sun, Jul 6, 2025 at 6:57 PM Dick Hardt <[email protected]> >>>>> wrote: >>>>> >>>>>> Did you look at the code? (Its JavaScript) :) >>>>>> >>>>>> bearer will fail as the startsWith() is looking for 'Bearer' >>>>>> >>>>>> If there is a starting space >>>>>> >>>>> >>>>> There's no such thing as a "starting space": >>>>> https://datatracker.ietf.org/doc/html/rfc9110#name-field-values >>>>> >>>>> >>>>>> or 2 spaces between Bearer and the token it will fail >>>>>> >>>>> >>>>> So what? >>>>> Are you suggesting changing a spec to please badly written/broken code‽ >>>>> Also, what it is that you consider "widely deployed" in your first >>>>> message? >>>>> >>>> _______________________________________________ >>>> OAuth mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
