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 <dick.ha...@gmail.com> 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 <wpa...@rhosys.ch> 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 <dick.ha...@gmail.com> 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 <t.bro...@gmail.com> wrote: >>> >>>> >>>> >>>> On Sun, Jul 6, 2025 at 6:57 PM Dick Hardt <dick.ha...@gmail.com> 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 -- oauth@ietf.org >>> To unsubscribe send an email to oauth-le...@ietf.org >>> >>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
